On Tue, Aug 18, 2009 at 7:15 AM, Florian Bösch <[email protected]> wrote: > > Where it becomes completely hairy is how to implement layouts. Layouts > with inner-restrictions are still fairly doable, you just have to > commit to draw your stuff in exactly the right order as the layout can > use it (though luck if you don't happen to keep your data in exactly > the same order as the GUI). Layout with outer constraints, where you > might need to figure out offsets/sizes based on how elements push you > around left/right/top/down are virtually impossible to do.
So then you go the hybrid-immediate route instead. Basically, your immediate mode code generates a tree, you update/layout/render the tree with a gui.end() call, and the tree is cached till next frame to provide coherency. That allows you to run over the tree as many times as necessary to handle events, again to recalculate any sort of layout, and finally to render. On the flip side, the state reduction of immediate mode GUIs is pretty much thrown out the window. Though I have a question about batched GUI rendering. It's my > understanding that for instance nvidia drivers reorder the primitives > in a vertex-list pretty much at random. > Certainly I have never encountered a driver that does this, and it would be more than a little problematic for everyone if it did - many applications depend on the order of elements in a vertex list (i.e. alpha-blended particle systems). -- Tristam MacDonald http://swiftcoder.wordpress.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
