Vista and Debugging your Paint methods. Cool!
Bob
methods much easier. I think its pretty cool if you do any custom
painting.
In XP and all prior versions, it was a pain if you needed a breakpoint
in your paint method. The breakpoint would fire, you walk through the
code, and as soon as you hit F9 it broke again. You were never able to
see what it actually drew unless you moved your form out of the way of
the IDE.
In Vista, this is much different. Put a breakpoint on your paint
method. Walk through what ever you like. Then hit F9. Switch to your
app and back to the IDE and the breakpoint will not fire. Only until
you do something that truely invalidates your paint area will the
breakpoint hit again. This is nice. No more OutputDebugStr in the
paint method.
--
Gerrit Beuze
> Has anyone noticed, under Vista, you can actually debug your paint
> methods much easier. I think its pretty cool if you do any custom
> painting.
Good news.
But bad news if you hide your licensing checking in paint methods
as I know quite a few companies do ;-))
Gerrit Beuze
ModelMaker Tools
Bob
> But bad news if you hide your licensing checking in paint methods
> as I know quite a few companies do ;-))
Scratching my head?? Why would you check in the paint method? How
often would someone need to check it? Seems a little overkill to me.
But maybe I don't understand whats being done.
--
Liz
> Scratching my head?? Why would you check in the paint method? How
> often would someone need to check it? Seems a little overkill to me.
> But maybe I don't understand whats being done.
Paint methods can get very complex, Id agree its likely once setup they
dont get changed that often, but it was always a problem that if you
did try and step through it.. you couldnt
--
Liz the Brit
Delphi things I have released: http://www.xcalibur.co.uk/DelphiThings
Nicholas Brooks
Hey, That is pretty cool.
Though for those of use that are still stuck on <= Windows XP you could
use a 2 monitor setup to debug your app. Delphi on one side and your
app on the other.
Cheers
Nicholas
Nils Haeck
>> methods much easier. I think its pretty cool if you do any custom
>> painting.
This probably means Vista stores the actual window bitmap, so when doing
z-buffer changes (moving windows back and forward), no new painting is
required, Vista just uses the cached bitmap.
> But bad news if you hide your licensing checking in paint methods
> as I know quite a few companies do ;-))
Why is this a problem? The windows needs to be painted *at least* one time.
Also, whenever an invalidate is called on the window from your code (when
something changes), it needs repainting, which is probably happening often
enough. The only change really is that there are a few more Paint calls in
the old system due to the user swapping focused windows.
Nils Haeck
www.simdesign.nl
Chris Morgan
>
> Though for those of use that are still stuck on <= Windows XP you could
> use a 2 monitor setup to debug your app. Delphi on one side and your app
> on the other.
Agreed; for me one of major benefits of a 2 monitor setup is that
debugging paint events becomes much easier!
Cheers,
Chris
RandomAccess
"Chris Morgan" <chris.nospam at lynxinfo dot co dot uk> wrote in message
news:45aa...@newsgroups.borland.com...
For me, debugging paint events becomes "possible".
Especially for controls such as listview and treeview where I almost always
override drawing.
best regards
Nathaniel L. Walker
> z-buffer changes (moving windows back and forward), no new painting is
> required, Vista just uses the cached bitmap.
Could this perhaps lead to increased performance of Windows Forms
applications on Vista compared to the same program running on Windows XP?
--
Nathaniel L. Walker
"The compiler should be your servant, not your
master."
Richard Stallman,
"GNU Coding Standards"
Thomas Mueller
Bob wrote:
> Has anyone noticed, under Vista, you can actually debug your paint
> methods much easier. I think its pretty cool if you do any custom
> painting.
>
> In XP and all prior versions, it was a pain if you needed a breakpoint
> in your paint method. The breakpoint would fire, you walk through the
> code, and as soon as you hit F9 it broke again. You were never able to
> see what it actually drew unless you moved your form out of the way of
> the IDE.
It has always been possible, all you had to do was making sure your IDE's
windows do not overlap with your application's windows. Alternatively you
could use the remote debugger.
MfG
twm
I.P. Nichols
>> This probably means Vista stores the actual window bitmap, so when doing
>> z-buffer changes (moving windows back and forward), no new painting is
>> required, Vista just uses the cached bitmap.
>
> Could this perhaps lead to increased performance of Windows Forms
> applications on Vista compared to the same program running on Windows XP?
Vista has a new Desktop Windows Manager that handles all of this. It
eliminates the "trails" left when you move a window across another window
that is underneath it.
"With Windows Vista, applications are asked by Windows to paint their entire
surface to an offscreen surface (alternatively known as a bitmap, buffer, or
texture), and it's up to the DWM to take all of these offscreen surfaces,
and "compose" them together to the onscreen buffer."
http://blogs.msdn.com/greg_schechter/archive/2006/03/05/544314.aspx
Nils Haeck
> applications on Vista compared to the same program running on Windows XP?
Hardly, it mostly has to do with window swapping. If your form shows e.g. an
animation or dynamic content, it still needs to repaint each time the
animation changes.
The new WDM (Windows Desktop Manager) makes windows paint to an offscreen
bitmap, then composes them to the desktop. This composition also allows for
transparency effects (glass), and more efficient dirty region management and
region culling. So, as someone else said, you e.g. get rid of the trails
when moving a window over another window.
This new "dirty region management" also seems to be the cause for the bugs
reported when running Delphi apps on Vista and pressing the ALT key.
I'd say this extra buffering puts even more strain on your system, so in
total it might actually slow down instead of speed up. For new hardware this
is probably optimized quite well though.
Just yesterday I watched a new video on channel 9, which explains this in
detail. It's worth watching if you want to know the internals of how Windows
renders graphics:
http://channel9.msdn.com/ShowPost.aspx?PostID=190430#190430
Kind regards,
Nils
Nils Haeck
Oops, should be DWM (Desktop Window Manager)
Nils
Cygnes
IDE's
>windows do not overlap with your application's windows. Alternatively
you
>could use the remote debugger.
>
>MfG
>twm
>
Since a few months I attached a second monitor to my laptop and I must
say, debugging has never been so easy. Just make sure you run the
application on the second monitor and you see everything during
debugging.
Robin
-------------------------------------
http://projectvalley.com
--- posted by geoForum on http://delphi.newswhat.com