RE: [boost] Re: C++ GUI - another view

Matt S Trentini wrote:
John Torjo wrote:
Could you elaborate a bit? What do you think is the window handle limit under win32?
I think that perhaps Mathew is talking about the GDI object limit. At least under Windows 2000 and earlier versions (I'm not sure about XP) there is a firm limit of 16K handles that can be allocated system wide - regardless of your particular specs (ie adding memory does not help). When this limit is reached weird stuff [1] happens which can only be fixed by a reboot.
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break.
Wouldn't you process the pen objects, etc. when handling the drawing event. Instead of storing a pen handle for each line (which IMHO is overkill), you would do something like: namespace gdi = boost::gdi; namespace colors = boost::gdi::colors; namespace units = boost::units; void draw( gdi::canvas & c ) { gdi::pen mypen( colors::lightskyblue ); gdi::font myfont( "Times New Roman", units::picas( 12 )); c.set_units( units::picas ); c.attach( mypen ); c.attach( myfont ); c.set_color( colors::red ); c.draw_string( 1, 1, "Hello World!" ); // uses myfont + colors::red c.line( 10, 10, 10, 15 ); // uses mypen c.line( 10, 15, 15, 15 ); // uses mypen c.line( 10, 10, 15, 15 ); // uses mypen c.attach( gdi::default_pen( colors::red )); // ... } Likewise, with the component framework (windows, widgets), it should be possible to implement windowless components that do not have a handle attached to them. This would be useful when implementing the layout managers. Handling an event should not be bound to the component that generates them. For example, MFC provides handling the exit message on the application object and not the main window object. This would then allow you to bind events to a graphical object without using a window handle. IMHO, line information should be separate from its colour, thickness, etc. Otherwise, you would need to do something like: class line_object { private: unit x1, y1, x2, y2; gdi::pen * pen; public: void draw( gdi::canvas & c ) { c.attach( *p ); c.draw_line( x1, y1, x2, y2 ); } }; which wastes a call to attach the pen each time. This is especially bad if you have 1000s of lines (e.g. drawing a hilbert curve or serpinski's triangle fractal with a fractal depth of 4 or more). Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY24-F25jJ8uT6Ssuo000635b5@hotmail.com...
Matt S Trentini wrote:
John Torjo wrote:
Any object that allocates a handle under Windows (pens, brushes, dc's, etc) consume those resources and if you've got a graphically intense GUI using a greedy GUI library (ie one that holds it's handles for a long duration) that limit isn't too hard to break.
Wouldn't you process the pen objects, etc. when handling the drawing event. Instead of storing a pen handle for each line (which IMHO is overkill), you would do something like:
I'd hope to keep the idea of acquiring and releasing system resources at a lower level. It then becomes the ( abstracted) output-devices job to acquire and release resources efficiently. For instance when drawing a 'stream' of lines, the stream might note a change in line colour, width,or style and only then see the need to change the 'pen', possibly with a cache, where resources that havent been used for a while are released. A similar approach might be applicable to GUI objects in general. Keep them as dumb as possible, until they are 'activated', and then dumb them down again if they dont appear to be being used. regards Andy Little
participants (2)
-
Andy Little
-
Reece Dunn