HOLY BLIT JAVAMAN! BeOS Java2D!!
I’m shaking as I write this. Seriously. I wasn’t expecting it to work at all tonight, but holy cow… This is just… Well, I’ll let the screenshot speak for itself.
Ok, so a little explanation of what’s going on here… There’s a lot. Seriously.
But unfortunately, there’s probably as much left to do as is done. Primarily — debugging.
I should clarify before you keep reading, that in Sun’s Java 1.4 (and I believe 1.2 and later) all graphics primitives are handled by the Java2D implementation. So getting the basic java.awt.Graphics class doing what it’s supposed to will result in almost all of Java2D being implemented and working. This is one milestone of many to come.
Right now we’re working with a stop-gap strategy for handling the Java2D backend, it’s slow right now. I have no idea how slow – I haven’t been able to keep it stable long enough to do anything usefull yet. :-p It’ll get there. There’s some locking issues right now — and there will be locking issues until we move to what I’m considering the ideal solution. I’ve been talking with darkwyrm about this the last few days – in another week or so I figure we’ll start on that solution in earnest. The official disclaimer is — this is a seriously early screenshot, of an extremely unstable devleopment branch. It’s slow, it crashes easily, and it dosen’t do everything it needs to, or will do.
The text in the top right hand, is draw with the g.drawString() function in the source code you see. This is -NOT- how fonts will look on the final BeOS Java2D implementation. Java2D has a lot of redundancies to make up for systems with crappy graphics capabilities. In order to get things ‘working’ and then optimize for BeOS later, the pipes that draw strings are currently using the Sun-supplied functions that draw directly to a bitmap buffer. Again, this is -not- the final text-rendering we’ll be using. The final product will have all the beauty of the BeOS graphics primitives. But that’s at least a week or two away at this point.
There’s a ton of work left to do, but this — this is great. We understand the design now, and we know what to do to add functionality. Yea!
If anyone heard a “OH HECK YEAH” coming from mississippi at 11:43 PM central US time, then that was probably me. :-D
Of course the title and reference to Javaman is a running joke from WalterCon. Ahhh good times, that Waltercon.
Update: 1:13 AM It’s stable. It’s slow, but it’s stable. Resizing the window no longer crashes the thing, and it’s redrawing. Very slow. Lots of flicker, but it’s stable… Next up – pixel pipes for non-text functions….
Since this gibberish post seems to be getting some attention from various news sites, I should probably mention that this server has been scheduled for a physical relocation tomorrow for well over a month. My brother, whom houses the server is relocating himself. Unfortunately, there will be downtime involved. Although the physcial relocation should take only approximately half an hour, how long it will DNS to update is anyones guess. Yes, this is bad timing. But you can’t pace or schedule code binges. They just sort of happen.

November 10th, 2004 at 3:26 am
Congrats! This is great. Even better to hear it’s stable now. Did you manage to fix the locking? So, what’s the next major obstacle?
November 10th, 2004 at 8:21 am
Yes, it’s locking. It’s bare minimum support for locking which results in clip regions the full size of the offscreen buffer being drawn to (among other nasties), but it is locking, and seems to work.
November 10th, 2004 at 4:44 pm
Hi Bryan!!
Firstly, I want congrat you by this milestone!! Keep up the good work!
Do you know something about OpenOffice port for BeOS??
Thanks Man!
Michael VinÃcius de Oliveira
~ BlueEyedOS.com Webmaster ~