Originally posted by al_bob:
[b]Stippling isn’t as simple as “just” using a 1D texture and picking the right texture coordinates:
I’d be interested in how you are all planning to replace it by 1D textures (or whatever else).[/b]
That’s exactly the point.
Line stippling breaks the GL paradigm of “self-contained primitives” or whatver you’d like to call it. I can’t imagine how you’d go on to build an implementation that can transform multiple vertices of a stippled line loop in parallel. For every other GL primitive this is perfectly possible and heavily exploited.
It’s f***ing complicated to do unless you have dedicated hardware for stippling and for stippling alone. Only very few applications use it, and those typically use it for only a handful of lines per frame (for selection regions aka “rubber bands”).
So, as an implementor, you have two choices
1)build dedicated hardware for something that’s needed for 1 per cent of all apps, and in these apps, for 1 per cent of all primitives.
2)don’t build dedicated hardware for stippling and instead layer it on top of your texturing and alpha test hardware. Yes, this approach will most likely require software transform for stippled lines to get the pattern offset right.
Would anyone notice the difference? I don’t think so. AFAICS there’s not a single application out there that would suffer a noticable performance loss.
Removing stipple from the core spec eases implementation for the choice #2 implementors.
The choice #1 implementors (if there are any!?) may want to expose it as an extension. That’s the preferred way to expose more outlandish features. Once we have PPPs, stippling will just be another redundant fixed function subset.
Originally posted by Korval
I don’t care much for display lists, and I don’t think they are particularly useful in terms of performance coding (their only real purpose) compared to VBOs. So I have no problem seeing them go.
I agree regarding geometry data. I disagree regarding state blocks. Display lists are tremendously useful for these purposes.
E.g. if you compile an abstract effect description into actual target state, you may end up with multiple thousand cycles of work. If you send this work to the current GL state, that work will be lost once you compile another effect. If you instead submit it to a display list, you can quickly reuse it later.
Shader programming extensions recognize this and encapsulate the programs in objects.
Pure state display lists have another interesting property: the contained state can be guaranteed to be error free and can be stored in the driver in the ‘real’ format (barring only one exception that I’m aware of - full search results ). CallList (for lists containing only state) can be implemented without error checking, as a simple series of memcpys and the setting of “state dirty” flags, in the majority of cases.
They are closely related to Push/PopAttrib in this respect.
Maybe display list should have been split between state and geometry from the start? So you’d have geometry lists and state lists.
If we pretend this had been the case all the time, I’d agree to tag geometry lists for removal, seeing how they’re now superseded by STATIC_DRAW VBOs (and VBOs are now a core feature).
If you still want to remove display lists altogether, you’re removing functionality that’s similar in infrastructure to Push/PopAttrib. If one goes, so should the other. In any case, I’d prefer that both stay. And finally, I think GL_COMPILE_AND_DRAW can be safely removed. Implementors generally advise against using it, so why would we want to keep it?
[This message has been edited by zeckensack (edited 02-01-2004).]
