Max
Do you want to send you a soldering iron? :-)
Neven
----- Original Message -----
From: Max Nilson <[EMAIL PROTECTED]>
To: Multiple recipients of list delphi <[EMAIL PROTECTED]>
Sent: Tuesday, 20 March 2001 18:28
Subject: RE: [DUG]: Number of lines in text file
> 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"
>
---------------------------------------------------------------------------
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"
