greyhoundcode wrote:Hey man -
I really hate to ask a question that is going to annoy you ... but any news on an advanced tab control?
Hey dude, no worries
well, I'll answer this question in a moment but first I'll let you know what's happening with the current development:
So far this is what's been fixed/added in the current pre-release build (V1.34)
- Fixed bug with GDI Plus notification hook/unhook under Windows XP (Microsoft bug).
- Fixed rendering bug with ExplorerBar (Reported by Zach).
- Fixed small device context handle leak on PanelEx resize.
- Fixed bug with AddPanelExPage when skinned control created and then AddPanelExPage called again (which added the page to the created control!).
- Fixed minor alignment bug with ButtonEx text and no icon.
- Fixed border rendering bug with alpha transparent PanelEx pages.
- Fixed bug with SetPanelExPageScrolling autoscroll not updating if called after controls created into page.
- Fixed/Improved alpha channel rendering of text (GDI doesn't support the alpha channel so ProGUI has to calculate and add it based on the pixel data).
- Changed behaviour of "Button" class with groupbox style (PB Frame3DGadget) when inside a PanelEx, now renders directly to PanelEx buffer (no longer flickers).
- Further optimized rendering of PanelEx, none ProGUI controls are now significantly faster at rendering inside a PanelEx.
- Changed rendering of alpha transparent PanelEx pages to use GDI AlphaBlend instead of GDI+, now considerably faster as hardware accelerated.
- Changed ImageButtonEx and TextControlEx internally to be subclassed PanelEx, less code in core drawpanel routine, smaller library size and more elegant design.
- Changed ButtonEx, ToggleButtonEx, RadioButtonEx, CheckButtonE, ExplorerBar Header/Item, text labels now support escape code effects and multiple lines!
- Changed ButtonEx, ToggleButtonEx, RadioButtonEx, CheckButtonEx, ExplorerBar Header/Item text, now shows ellipsis (...) when dimensions too small to contain all of the text.
- Added new GetTextControlExStyle command.
I'm currently designing a new internal image memory management system in preparation for the separate rendering subsystems i.e. Direct2D/DirectX, GDI/GDI+, Mac OS, Linux. The new system will use a fast 2D bin packing algorithm to pack all the separate images/buffers that are used into a "super buffer"/s of sizes to the power of 2 (512, 1024 etc...). This way optimizes GPU acceleration and storage of images inside the graphics card's memory and eradicates memory fragmentation. Also, When using the GDI subsystem ProGUI will only use a few GDI handles when compared to 500+ that an app usually uses (very important as GDI handles are a finite system wide resource). Another advantage is there will never be any duplication of the same image in memory (that might have been loaded more than once) as a MD5 hash will be used of the image data. The rendering speed should improve quite a bit as most of the bliting operations will be performed using just one buffer (that should be in graphics card memory as used very often
). Pretty cool huh?
So that's what will be in V1.34, here's a screen of some hardcore nested alpha transparent PanelEx's (can you guess how many PanelEx's there are?
)
I've also been quietly working on ProGUI V2.00 which the core is up and running and about half the source has been ported across into nice separate "module" includes which will make the source a lot easier to navigate. In ProGUI V2.00 I've been prototyping getting all the none ProGUI common controls to render onto a single buffer, I've managed to get this working using a combination of techniques - API hooking, subclassing, WM_Print and injecting input; which all means ProGUI and none ProGUI controls will be able to be used within a DirectX game for instance! (render to texture
)
Back to the original question heh The tab control will be coming (I personally want/need this control too!) but I think it's more important and valuable to get the different rendering subsystems working first rather than have to re-write control code at a later date. Hopefully this won't take too long though
Chris.
