Coding - it’s what the weekends are for.
Apparently it’s monday morning. I’m sitting in my cube writing this, so that pretty much coroborates the idea this is monday.
Spent most of my weekend letting things just slip by and pile up — mainly because I was working on the BeOS java port.
Lately I’ve been focusing on implmenting the necessary goodies for Java2D. From what I can tell, since the introduction of java 1.2 (Java2) all graphics functions for AWT have deferred to Java2D functions. It makes sense — having only a single abstraction for graphics makes it eaiser to implement. Just looking at the Java2D source for Windows makes me cringe. It’s a prime example of what happens when you have multiple graphics abstractions to work with. The Java2D implementation for Windows attempts to use DirectDraw as it’s primary method of drawing. But if DirectDraw fails, it uses GDI for a failover. It dosen’t sound like a bad idea. Until you get into cases where DirectDraw has initialized for a few objects, while possibly failing for others, resulting in a mix of DirectDraw & GDI as your graphics backend. The complexities of dealing with surface locking, object state, surface validity, and drawing pipes in this kind of environment are insane. Furthermore, there’s places in the code that explicitly outline some of the buggier and nastier problems. One such being no guaranteed order-of-execution when running in a mixed environment. A GDI call could succeede before a DirectDraw call (or vice-versa) and the results of the former call get lost by the execution of the latter. What?! I’m saying you could possibly loose screen updates. Not so much as loose them, but perceive to loose them - since they’re out of order.
Example: A parent panel with a single child, the panel is filled with a black rectangle, the child draws a red line. Normall execution order ensures that the parent is drawn before the child. In a mixed mode, where the parent is using DirectDraw and the child is using GDI the child draw -might- succeede before the parent draw, resulting in the child being overwritten, and the update being lost. Drawing in Java can happen from any thread at any given time, and without guaranteed OOE from the underlying platforms subsystem, you can end up with some funky results. I think I’ve actually seen this happen on Windows 2000 with TNT2 graphics cards using Java 1.4.0 — Swing applicaitons would have portions mystically disappear, normally when dealing with things like Button Labels. I’m not sure if that was the culprit, but it’s a possibility.
There’s a few entities that could be faulted as the cause for this. 1.) Hardware driver bugs — which are the reason DirectDraw would fail to init in the first place. 2.) Poor design on Sun’s behalf. Sure, taking advantage of DirectDraw is a good idea. But in order to do that they had to sell their soul to the GDI devil, and hope he played nice. 3.) Terrible design of a graphics subsystem on Microsofts’ behalf. Without guaranteed OOE of graphics calls being dispatched to different subsystems, developers cannot reliably mix DirectDraw and GDI without expensive, tricky locking and using a -lot- of thread local storage. For applications that don’t run exclusively in DirectDraw (or mix standard Win32 components with DirectDraw components) this becomes a serious hinderance to adopting the DirectDraw API. Granted, the application developers can take it on good faith that the driver writers have done more than their fair share and fix the problem at that level, but as history, human nature, and practical expirence tell us — this simply isn’t going to happen all the time.
What makes this even more amazing to me is that with Longhorn, MicroSoft is touting yet another graphics subsystem that you’ll be able to leverage in your applications! I’m going out on a limb here (not being a Windows developer, or having access to Longhorn) but I’m willing to guess the problems with OOE that exist in GDI - DirectDraw are going to get even worse when the combination becomes GDI - DirectDraw - Avalon. Insane? You betcha!
The good news is that for BeOS, this is totally a non-issue.
– End Of Rant –
I miss Be Inc. — when they set a direction they did it with ample fore-thought, and worked for the best possible solution. Such craftmanship seems to be a rare and dying part of the industry. Crap cobbeled together with even more crap. That’s how things are increasingly looking to me.
Aside from all the junk in the Windows Java2D code — I’m starting to think we’ve got a ton of complex code inherited from the existing AWT toolkits we’re working from (X11 and Win32) that we won’t need. I need to send off a few email’s to darkwyrm to make sure I’m correct on this — but I think we can drop a -ton- of complexity from our AWT…