"Garry Freemyer" <garryfre@pacbell.net.byespam> wrote in message
news:uqHfbhadFHA.3712@TK2MSFTNGP09.phx.gbl...
> Well, I suppose the way to nail it down would be to create a small version
> of this that just does a whole lot of grapics, I mean really stress the
> double-buffering, and show that it fails, or feel free to pack up my code
> to the screensaver and send it to them, there is a config option, where I
> chose auto-double buffering or manual buffering, and the first works, the
> second breaks horribly.
>
> By the way, InvalidOperationException, is NOT caught by a catch
> InvalidOperationException at all and those catches that do catch it have
> the exception stolen from them by the runtime. It's snatched away from
> their program by the runtime, which to me is a terrible thing to do to a
> programmer. I can only PARTIALLY catch it with a regular empty catch that
> I know I know it caught the error because the showcursor is executed, but
> the rest fails to execute because after the first line in the catch
> statement is execute and before the next line, the runtime kidnaps my
> error handling by somehow taking control away and putting up that cursed
> dialog box. Really, I see no excuse for a runtime kidnapping my code
> execution and fingering my code as if I did not write an exception handler
> at all - a cardinal sin of programming.
>
> It would only take a program that really stresses the system and
> demonstrates it in three modes ...
>
> 1. Double-buffering showing the breakage, the kidnapping of the error
> handler execution.
> 2. Auto Double Buffering showing that the program works. These two my
> program can do.
> 3. Showing how using flat 32 unmanaged code that gives ME control over
> when the backbuffer is drawn to the screen and when it's released solves
> the problem.
>
> The fact that GDI+ take away my ability to control when the backbuffer is
> applied, ought to be proof enough that the GDI isn't so much as broken,
> but is merely missing a vital piece of functionality. There is also the
> proof in the documentation itself that either the documentation is wrong
> or GDI+ stands for blank blank irritating and I bet you can guess what the
> first two words are.
>
> The closest to controlling when the backbuffer is written appears to be
> the flush command, but it contains all EXCEPT what I need because of the
> missing feature ...
>
> 1. Flush which strangely tells the system to start to write the
> backbuffer, BUT does so assynchroneously and yet says the command syncs
> the graphics objects?!!?? What is syncroneous about an assync operation?
> What This sets the program up for a blunder right then and there because
> then all I need is three with lines with auto buffering on...
>
> pev.Graphics.DrawSomethingbig(); // Draw something that will take a long
> time to draw.
> pev.Graphics.Flush(FlushIntention.Flush); // Start the drawing from the
> backbuffer to the screen...
> pev.Graphics.DrawAnything(); // Cause the InvalidOperationException error
> by trying to draw to the backbuffer while it is in an innaccessible state
> because it is being read or closing.
>
> 2. The Sync option, which the documentation says causes the program to
> wait till the flush is done before returning and then the docs turn around
> and says it "Syncs all graphics objects". Why would I be having more than
> ONE graphics object ultimately referring to the same buffer?? That would
> be like having a car where there are two drivers going to the same
> destination, but trying to take different routes? The docs are confusing
> at best, vague in the very least. My guess on this was that it is a
> write-now operation despite that it say to write as soon as possible
> implying that the command is assync!
>
> 3. What is missing is a method to tell the double-buffering NOT to write
> till I issue a flush command, otherwise, its guess work, on the part of
> GDI+ that is going to end up tripping over it's own feet.
>
> I suppose the GDI+ Auto-Double buffer could be considered broken and
> broken badly if it was intended that it would check first before trying to
> access the backbuffer for writing or reading while it's busy being read,
> or written or worse yet, being disposed, but then that begs the question
> about why would Migrosoft presume to imagine that all the diverse graphic
> needs could all be shoehorned into a narrow minded double buffering model
> that gives the programmer NO control over when the backbuffer is drawn.
> It's like a car with a huge accelleration pedel, but no brakes - It's
> going to crash!!
>
> I've been working on this saver, for weeks, I've seen this error about 80
> times, despite the fact that it can take up to 10 hours for it to show! It
> is exasperating in the extreme. I feel like I've spent half a million
> dollars putting together a custom built Citrine Mazaradi, and I am sitting
> in the garage all gassed up, polished up, in the driver seat ready to go
> the door is open, but I can't exit the garage because a piece of sand is
> in the way! Doh!
>
>
>
> 1. Running auto-double buffering, and get the error, which
> "Bob Powell [MVP]" <bob@_spamkiller_bobpowell.net> wrote in message
> news:ej1MlwZdFHA.2420@TK2MSFTNGP15.phx.gbl...
>> This is interesting because I've suspected for some time that double
>> buffering is broken and I've seen exceptions due to the use of automatic
>> double buffering on several occasions. It would be great to nail this
>> down and post it as a real bug report with MS.
>>
>> --
>> Bob Powell [MVP]
>> Visual C#, System.Drawing
>>
>> Find great Windows Forms articles in Windows Forms Tips and Tricks
>> http://www.bobpowell.net/tipstricks.htm
>>
>> Answer those GDI+ questions with the GDI+ FAQ
>> http://www.bobpowell.net/faqmain.htm
>>
>> All new articles provide code in C# and VB.NET.
>> Subscribe to the RSS feeds provided and never miss a new article.
>>
>>
>>
>>
>>
>> "Garry Freemyer" <garryfre@pacbell.net.byespam> wrote in message
>> news:uS1UbjWdFHA.3808@TK2MSFTNGP14.phx.gbl...