Corey Murtagh wrote:
> It'd be nice to be able to just pass it off as a problem with
> the video card, but from my experience few clients accept that.
> Unfortunately finding a solution is not always easy :(
Hear, hear!
> From all that I've heard and experienced about image lists,
> there are just too many problems to make them usable.
I'm not going to go that far, but there are certainly a raft of issues
that surround them that cause a lot of time to be wasted. Unfortunately
unless you are prepared to forgo standard common controls like the tool
buttons and trees, and the borland menus with glyphs, you are forced to
use the damn things.
> I do almost all of my image copying with API calls now... you
> get a little more control, and if something goes
> wrong you have a better chance of finding out what.
The sad part is that I have done this and half the problem has gone away.
But because I'm using the MaskedBlt API call, and this is the criminal in
most drivers we are still getting the nasty pink backgrounds. So I either
have to find a better implemented API that handled transparent mixing of
bitmaps, or I roll my own completly using DIB's and some tight code. Then
I can use just a simple BitBlt to get the bits to and from the screen, but
it is a real pain to do when the API's are there and have been available
for years!
> Also I tend to build an image in an off-screen buffer (a
> TBitmap for example) and blit them to the display using the
> simplest possible method (BitBlt, or TCanvas.CopyRect if
> you prefer). I have yet to have one freak on me doing it this
> way, and up until recently I had an S3-Trio64 card which had
> plenty of glitches of its own.
That was our conclusion, and I'm glad that you have found that this works.
Its just vasy annoying that code that works perfectly on the inhouse
machines with Matrox and nVidia cards and drivers, falls down the the real
world of cheap cards and crap drivers.
The solution that we are looking towards is to have the drawing behaviour
user configurable, so that if they have a good cards they won't have to
make any changes, but if they have the nasty pink drawing bug they can use
the non-device driver code and get clean but slower drawing. Our app
already leans very heavily on the machines to provied a nice GUI
experiance, and I don't really want to load the poor CPU any if the video
card can do a decent job for us, that's what its there for in the first
place.
Thanks for your comment, that have confirmed we are going the correct
route to fix this.
Cheers, Max.
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
