Re: Fastest way to move a compatibledc into a DC

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance


"Mike Williams" <mikea@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:uxSXZv0OIHA.4712@xxxxxxxxxxxxxxxxxxxxxxx
"Schmidt" <sss@xxxxxxxxx> wrote in message
news:eFCAxuvOIHA.5860@xxxxxxxxxxxxxxxxxxxxxxx

Not in case of an complex UserControl - DIBs
simply offer full control

You seem to have taken great offence to my statement Olaf,
almost as though you had invented DIBs yourself and felt as
though they were under attack :-)
???
DIBs simply support a broader range of usage-scenarios
and are more flexible than DDBs - and they offer a more
*reliable* performance - that's all I've said - without any
"emotions".

All I said was, "On lots of machines both of those things
[Autoredraw bitmaps and other Screen Compatible bitmaps]
will be more suitable and quite a lot faster than DIBs for
many tasks". My statement is true, and I stand by
it. Which specific part of it do you disagree with?
Thought I made that very clear in my post.
More suitable - no - because they are not as flexible
as DIBs regarding *your own stuff* (your own
PixelLoops).
And regarding performance I said yes, some Operations
work faster with DDBs if the Graphics-Driver supports the
operation - but I also tried to make clear, that if the Driver
doesn't support the Operation they are often slower than a
self implemented Pixel-Loop-Effect on DIBs. With DIBs
(wich usually means working against "normal" System-
Memory) you can count on the performance you measure -
no surprises possible because of the graph-Driver-independence
of DIB-Operations

[you can use DIBs for] Gradients and Blending-Effects
and also direct Rendering against the same Pixels over
a GDI-hDC

You can perform gradients and blending and lots of other
effects on Screen Compatible bitmaps as well, ...
Not with the same "degrees of freedom" as with DIBs.
Simply try a "Rounded-Corner-Gradient" on DDBs
(for all color-depths of course).

DIBs certainly do have their uses, but nothing in my
statement contradicts that.
I never said that they don't. I often use them myself for
various tasks. But so do Screen Compatible bitmaps have
their uses. Why do you seem so unwilling to accept that fact?
I've just given a recommendation from my point of
view - if you recommend DDBs and working against
the VB-AutoRedraw-Image - fine, do so - my experience
is another one (with sometimes not working - or very slow
performing AlphaBlend-Calls, with ColorDepth-Problems,
and with some complex Functions you will often not find
supported by the GDI). In the meantime most of the Bugs
inside the more complex GDI-Functions are probably fixed,
but I can only recommend using DIBs as soon as your
Control is getting complex and if you want some effects,
wich are not supported by the GDI.

In fact when dealing with code which draws things almost
solely for display purposes (as in the OP's case and as in
many other applications) then Screen Compatible bitmaps
are definitely the way to go,
No, not *definitely*. ;-)

especially as on many machines they are so very much faster.
As said, DIBs are fast enough on most modern machines +
they offer greater flexibility than DDBs because of their direct-
memory-access capabilities.
If one wants the most out of his graphics-card he should
look into DirectX or OpenGL.

+ you decide when and where what
areas of your DIBSection are (Stretch-)Blitted to
a Screen-DC.

Are you saying that you cannot do any of those things with a Screen
Compatible bitmap?
No, with this statement I was referring more to the AutoRedraw-
Image, wich by its "under the hood working" can cause some
nice effects for unexperienced users. If one implements a BackBuffer
himself (e.g. using DIBs) leaving VBs AutoRedraw untouched - there
are not that much surprises possible regarding efficient screen-refreshs.

[Mike said] On lots of machines both of those things
will be more suitable and quite a lot faster than DIB
Sections for many tasks.

[Olaf Schmidt said] More suitable - I'd doubt that

You are at liberty to doubt whatever you wish.
But I know that it is true.
I was doubting the term "more suitable", not the term
"quite a lot faster for many tasks".
As said, try to write a rounded corner-gradient for all
possible types of DDBs (8, 15, 16, 24 and 32Bits) and
you know what I mean.

- as I wrote above - fast Pixelmanipulation directly in
Memory (without Buffer-Swapping) is possible with
DIBSections - with DDBs this task is somewhat more
difficult.

More difficult perhaps, but not impossible.
Exactly what I mean. :-)

Besides, you keep harping on about this "direct pixel manipulation
in memory" as though it was the Holy Grail or something!
It is not the "Holy Grail" but needed quite often as soon as you
want to write a "modern looking" GUI-component (with
Gradients every here and then, AlphaBlending-Effects on
MouseEnter/MouseLeave, etc.)

In fact most people, as is evidenced by their various questions
on the group, hardly ever get involved with direct pixel manipulation
of bitmap data in memory and they instead draw their stuff and
manipulate their drawings using the standard GDI drawing and
blitting methods.
Agreed, but some of them maybe want to read about approaches
of others, wich offer a broader "usage-range". Don't underestimate
the "average Group-User".

"Quite a lot faster" - maybe for some tasks
Yes. That's what I said. "Quite a lot faster than DIBSections for
many tasks" was my precise phrase. I'm glad you agree with me.
My pleasure. :-)

And I don't mean just a bit faster. I'm talking about *very much
faster*!
Fine, and I'm talking about "sometimes slower, if the graphics-driver
doesn't support the needed action in hardware".

If I run anything on any computer it will only use features that the
hardware actually supports! Are you saying that *all code* should
be "dumbed down" so as to run at the same speed on all machines
as it does on slow machines with dodgy hardware? Is that what you
really think?
No Mike, what I'm saying is, that even on actual machines many
*graphics-drivers* do *not* support every complex GDI-Call in
hardware.
On the other hand every actual machine today has a fast processor
and a fast memory interface (at least much faster than on my old
Test-Notebook with a PIII500 and 384MB of slow working
Ram). If working against DIBs on this machine is "Ok", then it
is "more than Ok" on all of the other hardware currently out there.

[DDBs and hardware-support]
They will happily use whatever facilities the hardware provides,
and that's as it should be.

With DIBs you can normally count on the performance
you measure.

You can count on the performance you measure with Screen
Compatible Bitmaps as well!

Not in every case - but maybe it is better these days.
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba
ckID=100477
http://groups.google.de/group/microsoft.public.vb.general.discussion/msg/3e
4d6681ea7be785
Not to mention the StretchBlt-Halftone-support on Win98.

DIB-Performances scales very well (nearly linear) with
the CPU-Performance and with the Performance of the
Memory-SubSystem.

You make that sound like an advantage! The performance
of many things scales according to CPU performance and
memory speed. What's special about that?
The fact, that you cannot rely on that CPU-performance and
the performance of the System-Memory as soon as you
give the job to the graphics-processor and the graphic-
memory. As shown above, there are cases where the graphics-
hardware-support "sucks". Then the performance is often
much lower than what you can achieve with DIBs.

In fact I've just tried some fairly bog simple standard sprite
animation code (nothing fancy, just animating a number of
medium sized sprites transparently over a background picture)
and using DIBs I can animate about 35 to 40 sprites at a frame
rate of about 60 Hz on this machine. If I use Screen Compatible
bitmaps instead I can animate more than 500 of them at the
same 60 Hz frame rate.
Just because of interest, can you put this Sprite example online
somewhere, so that I can see what you are doing there?

Are you seriously suggesting that a program should deliberately
and specifically fail take advantage of a system's hardware?
In the context of Control-Development, wich this thread
has as the common topic - yes, because they are fast enough
and are more flexible.

For game-development I'd choose DirectX or OpenGL ;-)

You can religiously stick to your DIBs for everything if you wish,
DIBs are just *my* recommendation for complex Usercontrols in
VB - and I've done (and currently do) a lot of Control-Development.
They are the "no surprises"-way with more than enough performance.
I see no religion here - if you don't want to follow that - don't do it.

but personally I will use DIBs or Screen Compatible bitmaps or
whatever else I want to use, whichever suits the occasion.
It's horses for courses. I'll use DIBs when I feel that DIBs are
appropriate ...
Glad you agree with me finally.
I use DIBs where I feel they are appropriate - for VB-Control-
development. :-)

Olaf


.

Relevant Pages

  • Re: Fastest way to move a compatibledc into a DC
    ... You seem to have taken great offence to my statement Olaf, almost as though you had invented DIBs yourself and felt as though they were under attack :-) All I said was, "On lots of machines both of those things [Autoredraw bitmaps and other Screen Compatible bitmaps] will be more suitable and quite a lot faster than DIBs for many tasks". ... If I run anything on any computer it will only use features that the hardware actually supports! ... Blitting the same 800 x 600 pixel bitmap using Screen Compatible bitmaps the code finishes executing almost instantaneously with the processor immediately being available for other tasks while the video card hardware gets on with the actual blitting job, which incidentally it carries out in just 900 microseconds instead of the DIB's 5600 microseconds. ...
    (microsoft.public.vb.general.discussion)
  • Re: Fastest way to move a compatibledc into a DC
    ... I'll use DIBs when I feel that DIBs are ... In the case of most real time graphics manipulation it is better to use whatever method happens to be the most appropriate for that specific set of circumstances, and on many machines for many tasks that will be Screen Compatible bitmaps rather than DIBs by a *very large* margin. ... Why would you ever want to deliberately cripple your program in the way that you have suggested simply in order to stick with your DIB religion? ...
    (microsoft.public.vb.general.discussion)