Neven MacEwan kindly said:
> You are right (as usual)
Probably from a considered effort to think hard then port if I know
something relevant. You'll notice many time I say nothing in an attempt to
conceal my ignorance of the topic under discussion 8-)
> that the VM manager would be the best solution as it gets the
> first bite of the cherry. It does of course mean you are a bit
> at the mercy of the OS, something most of us would hate to
> admit (let alone acknowledge)
I acknowledge it! In fact I acknowledge daily while sending imprecations
down on the Microsoft and Intel engineers that cause me support troubles.
For anyone that cares the latest in the extremely long running saga of
large images list goes something like this. We have found that certain
crappy video drivers (Intel i810, S3 Trio etc) can't handle large image
lists and either draw random pixels, or fail to do transparent drawing
leaving lots of pink pixels on the screen, or die with errors in
DIBENG.DLL (a horrible MS DLL that video drivers can use to help if they
are too stupid to write their own code for some driver stuff).
So after various work arounds I finally solved the problem by hacking up
my own transparent blitting code that used device independent bitmaps to
mix the source and destination pixels and then blitted these to the
screen. You'd think that a routine with three bit-blits, each doing simple
SRCCOPY operations world work on all drivers wouldn't you?
But no. Now we get customers running machines with Intels integrated video
complaining about serious crashed in DIBENG.DLL (nice cheap machine don't
you know?). And this is one of those app caused illegal operation dialogs
that prompt kills you application, no exception handling or nothing.
Telling them to get a real video card is out of the question, so we get
our hands on an offending box and instrument our code up the wazoo, and
find that the DIBENG.DLL death is happening some random time after the my
transparent blitting routine is exited, but before the pixels make it to
the screen! So in a last ditch attempt for an answer we crank the graphics
accelerator setting down and the bug does away. After some more testing we
find that no acceleration, and basic acceleration works and anything more
dies.
As far as we can tell the video driver is doing some fancy pixel caching
to up its drawing rate, and is stuffing up with our mix of drawing code.
And all we are doing at that point is DIB bitmap blits and text drawing.
Not that complex and certgainly not any that can be simplified.
So now we get to tell our users that thanks to Intels crappy drivers they
have to turn down their video acceleration, or our application won't work.
How's that for a lovely situation to be in.
So yes, I acknowledge we are completely at the mercy of hundreds of
unknown, and probably under paid MS and Intel coding serfs that can make
our application look shit because of their code. No to mention all the
other device driver authors out there. That's probably why we all try and
forget that fact as we do our work, because its sort of depressing in a
way.
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"
