<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Dead On!</title>
	<atom:link href="http://www.varnernet.com/~bryan/2005/06/01/dead-on/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.varnernet.com/~bryan/2005/06/01/dead-on/</link>
	<description>The Runnoff of my brain, in Digital Form</description>
	<lastBuildDate>Wed, 14 Sep 2011 01:01:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Bryan</title>
		<link>http://www.varnernet.com/~bryan/2005/06/01/dead-on/comment-page-1/#comment-890</link>
		<dc:creator>Bryan</dc:creator>
		<pubDate>Tue, 07 Jun 2005 00:12:20 +0000</pubDate>
		<guid isPermaLink="false">http://bryan.varnernet.com/archives/2005/06/01/dead-on/#comment-890</guid>
		<description>My sincere apologies, Andy.

I look forward to this next installment!

I suppose using Swing &quot;vs&quot; SWT was a bit misleading. I should have said you somewhat compare / contrast them, and point out some rather nice debunkers for the crowd that insists uniformity is the only way.

I don&#039;t think I should point my finger any further than Apple to show that companies often make &quot;usability guides&quot; and then break them by skinning some apps. *cough*Safari*cough*

Anyway, I&#039;ll leave that one alone.</description>
		<content:encoded><![CDATA[<p>My sincere apologies, Andy.</p>
<p>I look forward to this next installment!</p>
<p>I suppose using Swing &#8220;vs&#8221; SWT was a bit misleading. I should have said you somewhat compare / contrast them, and point out some rather nice debunkers for the crowd that insists uniformity is the only way.</p>
<p>I don&#8217;t think I should point my finger any further than Apple to show that companies often make &#8220;usability guides&#8221; and then break them by skinning some apps. *cough*Safari*cough*</p>
<p>Anyway, I&#8217;ll leave that one alone.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: arooaroo</title>
		<link>http://www.varnernet.com/~bryan/2005/06/01/dead-on/comment-page-1/#comment-886</link>
		<dc:creator>arooaroo</dc:creator>
		<pubDate>Sun, 05 Jun 2005 20:28:02 +0000</pubDate>
		<guid isPermaLink="false">http://bryan.varnernet.com/archives/2005/06/01/dead-on/#comment-886</guid>
		<description>Andy Roberts here. Glad to discover that someone read my article! ;) One point though, I *didn&#039;t* write an article about SWT vs Swing - I wrote an article about Java looks, which briefly mentioned SWT, but focused mainly on improving Swing&#039;s look and feel.

For those interested in SWT, you can expect an interview SWT lead dev, Steve Northover (from IBM) to appear on OSNews in the near future. The third part in my Java &#039;debate&#039; series will be published early next week, and will concern Java/OSS issues. 

Also, during your blog, my name suddenly switched to &#039;Adam&#039; - which it isn&#039;t! ;)</description>
		<content:encoded><![CDATA[<p>Andy Roberts here. Glad to discover that someone read my article! ;) One point though, I *didn&#8217;t* write an article about SWT vs Swing &#8211; I wrote an article about Java looks, which briefly mentioned SWT, but focused mainly on improving Swing&#8217;s look and feel.</p>
<p>For those interested in SWT, you can expect an interview SWT lead dev, Steve Northover (from IBM) to appear on OSNews in the near future. The third part in my Java &#8216;debate&#8217; series will be published early next week, and will concern Java/OSS issues. </p>
<p>Also, during your blog, my name suddenly switched to &#8216;Adam&#8217; &#8211; which it isn&#8217;t! ;)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan</title>
		<link>http://www.varnernet.com/~bryan/2005/06/01/dead-on/comment-page-1/#comment-880</link>
		<dc:creator>Bryan</dc:creator>
		<pubDate>Fri, 03 Jun 2005 14:23:23 +0000</pubDate>
		<guid isPermaLink="false">http://bryan.varnernet.com/archives/2005/06/01/dead-on/#comment-880</guid>
		<description>Sun provides a default set of cross-platform native rendering pipes for Java2D. Getting them to work with BBitmap was a trivial issue (BBitmap-&gt;Buffer() returns a pointer to the start of the bitmaps raster in memory). The Sun-supplied graphics functions are fast, work well, and support everything that&#039;s needed in Java2D. There are places we can probably speed things up in the future, but it may have to wait for Haiku or some OSBOS API for accelerated graphics.

So yes, we&#039;re bypassing the app_server for all Java2D drawing. The only time the app_server is used is to draw the surface bitmaps. The problem with this is that transferring bitmaps from the client program to the app_server gets expensive quickly. There&#039;s a few things we&#039;re doing to speed this up for R5, so far it&#039;s been very useable on my laptop, even when it&#039;s clocked to 600Mhz. If some of the things I&#039;m planning to try out end up working, we should be able to eliminate the BBitmap transfer alltogether on machines that support BDirectWindow... I may be spilling the beans here, as I have absolutely no idea if that will work at all. Just a hunch that it would.</description>
		<content:encoded><![CDATA[<p>Sun provides a default set of cross-platform native rendering pipes for Java2D. Getting them to work with BBitmap was a trivial issue (BBitmap-&gt;Buffer() returns a pointer to the start of the bitmaps raster in memory). The Sun-supplied graphics functions are fast, work well, and support everything that&#8217;s needed in Java2D. There are places we can probably speed things up in the future, but it may have to wait for Haiku or some OSBOS API for accelerated graphics.</p>
<p>So yes, we&#8217;re bypassing the app_server for all Java2D drawing. The only time the app_server is used is to draw the surface bitmaps. The problem with this is that transferring bitmaps from the client program to the app_server gets expensive quickly. There&#8217;s a few things we&#8217;re doing to speed this up for R5, so far it&#8217;s been very useable on my laptop, even when it&#8217;s clocked to 600Mhz. If some of the things I&#8217;m planning to try out end up working, we should be able to eliminate the BBitmap transfer alltogether on machines that support BDirectWindow&#8230; I may be spilling the beans here, as I have absolutely no idea if that will work at all. Just a hunch that it would.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

