Vector GUIs (a follow up)
Posted: Thu Mar 16, 2006 14:11
[edit] er.. this was supposed to be a reply to the previous "Vector GUIs" thread, but I hit some funky key combos or something, and it ended up as this new thread.[/edit]
Just a little follow up. I was reading over someone's post to the wxPython list to the effect of "vector guis are nice -- but of course to speed it up it's good to cache the results in bitmaps."
I hadn't considered that. But if that's the case then, whoa, you don't need to create a back end specially for doing a vector gui! You can still work in happy CEGUI texture-mapping land. The only difference is that instead of getting your textures from static bitmaps, you rebuild them on the fly whenever a widget is resized. All you need is a new type of image source and the hooks for that image source to be notified when things need to be redrawn, and voila, you can have a vector GUI using whatever backend you want.
This may have been what you were thinking about, Lindquist, but it totally hadn't occurred to me. Doing it that way makes it into a much more feasible project.
Just a little follow up. I was reading over someone's post to the wxPython list to the effect of "vector guis are nice -- but of course to speed it up it's good to cache the results in bitmaps."
I hadn't considered that. But if that's the case then, whoa, you don't need to create a back end specially for doing a vector gui! You can still work in happy CEGUI texture-mapping land. The only difference is that instead of getting your textures from static bitmaps, you rebuild them on the fly whenever a widget is resized. All you need is a new type of image source and the hooks for that image source to be notified when things need to be redrawn, and voila, you can have a vector GUI using whatever backend you want.
This may have been what you were thinking about, Lindquist, but it totally hadn't occurred to me. Doing it that way makes it into a much more feasible project.