From Oleg.Sukhodolsky at Sun.COM  Sat Dec  1 02:38:42 2007
From: Oleg.Sukhodolsky at Sun.COM (Oleg Sukhodolsky)
Date: Sat, 01 Dec 2007 05:38:42 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with Xorg
 server 1.3.0+	(I'm	ready to work on a patch)
In-Reply-To: <1196455116.9594.7.camel@dylan>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
Message-ID: <4750C932.3090908@sun.com>

Hi Dan,

am I right that your are going to fix our code so it correctly handled 
situation when Xinerama is loaded but we have just one screen, so we 
could use Xrandr extension in such configuration?

This code is somewhere on boundary of AWT and 2D areas so you may want 
to also check with 2D.  As for AWT side I can say for sure that we do 
not work on similar issue.

 > I've still not opened a bug on the Java bug database, do I need to do
 > that to be tidy?

you are supposed to send a path with bug id, so it looks reasonable to 
have one :)

Regards, Oleg.

Dan Munckton wrote:
>> Or maybe could the code in awt_GraphicsEnv.c check if only 1 monitor
>> is connected and presume that it's the Xrandr backend that's in use as
>> Xinerama wouldn't be loaded in that situation?
> 
> I tested this out and of course it works on my single monitor setup. 
> 
> Since then I've chatted with Adam Jackson (Redhat) on #xorg he advised
> that if XRRQueryVersion() returns >= 1.2, Java should go ahead and use
> RANDR even if Xinerama is present.
> 
> So I'd like to go ahead and work on a patch for this. Could anyone
> confirm if this is ok and that I'd not be duplicating effort?
> 
> I've still not opened a bug on the Java bug database, do I need to do
> that to be tidy?
> 
> Any tips on how to go about writing a jtreg test for this?
> 
> Cheers
> 
> Dan
> 
> 
> 


From lists at munckfish.net  Mon Dec  3 20:25:42 2007
From: lists at munckfish.net (Dan Munckton)
Date: Mon, 03 Dec 2007 20:25:42 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with Xorg
	server 1.3.0+ (I'm	ready to work on a patch)
In-Reply-To: <4750C932.3090908@sun.com>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com>
Message-ID: <1196713542.6134.16.camel@dylan>

Hi Oleg

Thanks for your reply.

> am I right that your are going to fix our code so it correctly handled 
> situation when Xinerama is loaded but we have just one screen, so we 
> could use Xrandr extension in such configuration?

Yes. I'm happy to try and produce a patch if there's no-one else working
on this issue. My employer's product will soon be directly affected by
the problem so I'm very motivated to see it solved as soon as possible.

This would be my first contribution to Java/OpenJDK and therefore I may
not progress as quickly as others who are already involved. Is it true
that new contributors are assigned a mentor to assist a little?

> This code is somewhere on boundary of AWT and 2D areas so you may want 
> to also check with 2D.  As for AWT side I can say for sure that we do 
> not work on similar issue.

Hello 2d-dev, is there anyone aware of/working on this problem already?
(http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000109.html)

> 
>  > I've still not opened a bug on the Java bug database, do I need to do
>  > that to be tidy?
> 
> you are supposed to send a path with bug id, so it looks reasonable to 
> have one :)

I have now opened a bug which has been assigned an id. It's not yet
visible in the external database but here's the link anyway:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469

Thanks

Dan



From Dmitri.Trembovetski at Sun.COM  Mon Dec  3 21:08:16 2007
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Mon, 03 Dec 2007 13:08:16 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with
 Xorg	server 1.3.0+ (I'm	ready to work on a patch)
In-Reply-To: <1196713542.6134.16.camel@dylan>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com> <1196713542.6134.16.camel@dylan>
Message-ID: <47547040.2070606@Sun.COM>


   Hi Dan,

   thank you for filing the bug. I found your posts
   on various forums when researching for bug 6599351.

Dan Munckton wrote:
>> am I right that your are going to fix our code so it correctly handled 
>> situation when Xinerama is loaded but we have just one screen, so we 
>> could use Xrandr extension in such configuration?
> 
> Yes. I'm happy to try and produce a patch if there's no-one else working
> on this issue. My employer's product will soon be directly affected by
> the problem so I'm very motivated to see it solved as soon as possible.

   BTW, someone posted a hackish work around for this issue
   (see 6636469).

> This would be my first contribution to Java/OpenJDK and therefore I may
> not progress as quickly as others who are already involved. Is it true
> that new contributors are assigned a mentor to assist a little?
> 
>> This code is somewhere on boundary of AWT and 2D areas so you may want 
>> to also check with 2D.  As for AWT side I can say for sure that we do 
>> not work on similar issue.
> 
> Hello 2d-dev, is there anyone aware of/working on this problem already?
> (http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000109.html)
> 
>>  > I've still not opened a bug on the Java bug database, do I need to do
>>  > that to be tidy?
>>
>> you are supposed to send a path with bug id, so it looks reasonable to 
>> have one :)
> 
> I have now opened a bug which has been assigned an id. It's not yet
> visible in the external database but here's the link anyway:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469

   As I mentioned in my evaluation (you should see it shortly *)
   this bug is related to this one:
      http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6599351

   I think this should be addressed by two fixes:
     1. we need to correctly detect whether Xinerama is present and
        active (6599351)
     2. as you suggested we should relax the requirement concerning
        xinerama and randr (6636469)

   The first part (arguably =) belongs to AWT and will need to work
   correctly on both linux ans solaris (with newer Xorg servers).

   The second part belongs to 2D. I guess for the sake of simplicity
   we could fold both issues into the same bug report since they both
   have same underlying cause.
   Typically we close the newer bug as a duplicate of the older one.
   What do you think?

   Thanks,
     Dmitri
   Java2D Team

   *) You can sign up for Java2D related bug updates, that way you
      will see the new bug reports and updates as they come in:
        http://mail.openjdk.java.net/mailman/listinfo/2d-bugupdates



From linuxhippy at gmail.com  Tue Dec  4 14:55:33 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 4 Dec 2007 15:55:33 +0100
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for the X11
	pipeline?
Message-ID: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>

Hello,

I've some spare-time left so maybe I find some time to implement the
most used software-fallbacks using XRender. There has been significant
progress when it comes to XRender. With the EXA framework a few
open-source drivers will soon be capable of accalerating fancy things,
and nvidia has excellent XREnder accelaration in their latest binary
driver.

I wonder what would be better:
- Copy the source and implement an "XRender" pipeline replacing as
much of X11 drawing functionality as possible.
- Extend the existing one and let software-fallbacks there if no
XRender is available.

I would prefer the second, since XRender is just another extension.

lg Clemens


From jesse at mbuki-mvuki.org  Tue Dec  4 15:11:15 2007
From: jesse at mbuki-mvuki.org (Jesse W. Hathaway)
Date: Tue, 4 Dec 2007 10:11:15 -0500
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for the
	X11 pipeline?
In-Reply-To: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
Message-ID: <20071204151114.GA11334@mbuki-mvuki.org>

> Hello,
> 
> I've some spare-time left so maybe I find some time to implement the
> most used software-fallbacks using XRender. There has been significant
> progress when it comes to XRender. With the EXA framework a few
> open-source drivers will soon be capable of accalerating fancy things,
> and nvidia has excellent XREnder accelaration in their latest binary
> driver.
> 
> I wonder what would be better:
> - Copy the source and implement an "XRender" pipeline replacing as
> much of X11 drawing functionality as possible.
> - Extend the existing one and let software-fallbacks there if no
> XRender is available.

Has creating a Cairo, cairographics.org, pipeline been considered? A 
Cairo pipeline would give you software fall backs as well as 
acceleration when available. Also given the increasing interest in 
using Cairo for X11 rendering its performance should only get better 
over time. Finally you could compare performance across Windows and
OSX since Cairo supports both platforms.

-Jesse


From linuxhippy at gmail.com  Tue Dec  4 15:23:39 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 4 Dec 2007 16:23:39 +0100
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for the
	X11 pipeline?
In-Reply-To: <20071204151114.GA11334@mbuki-mvuki.org>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
Message-ID: <194f62550712040723p70f69ec6g49b64e9c82338455@mail.gmail.com>

> Has creating a Cairo, cairographics.org, pipeline been considered? A
> Cairo pipeline would give you software fall backs as well as
> acceleration when available.
Well I would welcome a Cairo-Java2D implementation, although I don't
see many benefits. However choice is never a bad idea if its offered
for free.
If you don't plan to do it ... its the usual problem with OSS
projects: Many people telling others what they should do, but only a
few writing code. Sorry for beeing not friendly ;)

> Finally you could compare performance across Windows and
> OSX since Cairo supports both platforms.
Yes Cairo supports both platforms, but performance differs a lot on
different platforms, except if you use software-rendering which is not
something desireable.

lg Clemens


From jesse at mbuki-mvuki.org  Tue Dec  4 16:33:56 2007
From: jesse at mbuki-mvuki.org (Jesse W. Hathaway)
Date: Tue, 4 Dec 2007 11:33:56 -0500
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for the
	X11 pipeline?
In-Reply-To: <194f62550712040723p70f69ec6g49b64e9c82338455@mail.gmail.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<194f62550712040723p70f69ec6g49b64e9c82338455@mail.gmail.com>
Message-ID: <20071204163356.GC11334@mbuki-mvuki.org>

> > Has creating a Cairo, cairographics.org, pipeline been considered? A
> > Cairo pipeline would give you software fall backs as well as
> > acceleration when available.
> Well I would welcome a Cairo-Java2D implementation, although I don't
> see many benefits. However choice is never a bad idea if its offered
> for free.

I think the primary benefits are: precise vector based graphical output,
insulation from direct X11 drawing operators, and multiple acceleration
backends (OpenGL, Render via xlib or XCB).

> If you don't plan to do it ... its the usual problem with OSS
> projects: Many people telling others what they should do, but only a
> few writing code. Sorry for beeing not friendly ;)

agreed, no offense taken

> > Finally you could compare performance across Windows and
> > OSX since Cairo supports both platforms.
> Yes Cairo supports both platforms, but performance differs a lot on
> different platforms, except if you use software-rendering which is not
> something desireable.
> 
> lg Clemens

-- 
The trenchant blade, Toledo trusty,
For want of fighting was grown rusty,
And ate into itself, for lack
Of somebody to hew and hack.
                     -- Samuel Butler


From linuxhippy at gmail.com  Tue Dec  4 16:45:28 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 4 Dec 2007 17:45:28 +0100
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for the
	X11 pipeline?
In-Reply-To: <20071204163356.GC11334@mbuki-mvuki.org>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<194f62550712040723p70f69ec6g49b64e9c82338455@mail.gmail.com>
	<20071204163356.GC11334@mbuki-mvuki.org>
Message-ID: <194f62550712040845h372fc0fake19c82d44ace26d2@mail.gmail.com>

> I think the primary benefits are: precise vector based graphical output,
> insulation from direct X11 drawing operators, and multiple acceleration
> backends (OpenGL, Render via xlib or XCB).
I agree to some degree - and if I would have to write java from
scratch I would immediatly choose cairo as API for 2d rendering. (not
creating Java2d api on top of it)
However for Java2D almost everything is already there (GDI, Direct3d,
OpenGL, X11, Quarzt, Software, ...), its working well :) and layering
Java2D on top Cairo probably isn't that simple.

> agreed, no offense taken
Thats great, it was not my intention to offend you.

lg Clemens


From Yuri.Nesterenko at Sun.COM  Tue Dec  4 13:16:39 2007
From: Yuri.Nesterenko at Sun.COM (Yuri Nesterenko)
Date: Tue, 04 Dec 2007 16:16:39 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with Xorg
 server 1.3.0+ (I'm	ready to work on a patch)
In-Reply-To: <1196713542.6134.16.camel@dylan>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com> <1196713542.6134.16.camel@dylan>
Message-ID: <20071204131639.GA9128@frigate.russia.sun.com>

Hi Dan,

this new bug, 6599351, seems to be about the same issue, isn't it?
It should be fixed in several releases, as I understand.

Now let's decide: if you will create a patch for your bug then I'll not 
work on my,  otherwise I'll start but not very fast, either. Anyway, 
after your patch is ready for jdk7, I can port it to earlier non-open releases
where applicable. 
Oleg or/and I, we can help when necessary and review your code.

Thanks,
-Yuri

On Mon, Dec 03, 2007 at 08:25:42PM +0000, Dan Munckton wrote:
> Hi Oleg
> 
> Thanks for your reply.
> 
> > am I right that your are going to fix our code so it correctly handled 
> > situation when Xinerama is loaded but we have just one screen, so we 
> > could use Xrandr extension in such configuration?
> 
> Yes. I'm happy to try and produce a patch if there's no-one else working
> on this issue. My employer's product will soon be directly affected by
> the problem so I'm very motivated to see it solved as soon as possible.
> 
> This would be my first contribution to Java/OpenJDK and therefore I may
> not progress as quickly as others who are already involved. Is it true
> that new contributors are assigned a mentor to assist a little?
> 
> > This code is somewhere on boundary of AWT and 2D areas so you may want 
> > to also check with 2D.  As for AWT side I can say for sure that we do 
> > not work on similar issue.
> 
> Hello 2d-dev, is there anyone aware of/working on this problem already?
> (http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000109.html)
> 
> > 
> >  > I've still not opened a bug on the Java bug database, do I need to do
> >  > that to be tidy?
> > 
> > you are supposed to send a path with bug id, so it looks reasonable to 
> > have one :)
> 
> I have now opened a bug which has been assigned an id. It's not yet
> visible in the external database but here's the link anyway:
> 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
> 
> Thanks
> 
> Dan


From lists at munckfish.net  Tue Dec  4 21:47:27 2007
From: lists at munckfish.net (Dan Munckton)
Date: Tue, 04 Dec 2007 21:47:27 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with
	Xorg	server 1.3.0+ (I'm	ready to work on a patch)
In-Reply-To: <20071204131639.GA9128@frigate.russia.sun.com>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com> <1196713542.6134.16.camel@dylan>
	<20071204131639.GA9128@frigate.russia.sun.com>
Message-ID: <1196804847.14367.2.camel@dylan>

Hi Yuri, Dmitri

Thanks for your replies. I'm sorry I've had a hell of a day, I will make
time tomorrow morning to read through the other bug reports properly and
give you a proper reply.

Cheers

Dan

On Tue, 2007-12-04 at 16:16 +0300, Yuri Nesterenko wrote:
> Hi Dan,
> 
> this new bug, 6599351, seems to be about the same issue, isn't it?
> It should be fixed in several releases, as I understand.
> 
> Now let's decide: if you will create a patch for your bug then I'll not 
> work on my,  otherwise I'll start but not very fast, either. Anyway, 
> after your patch is ready for jdk7, I can port it to earlier non-open releases
> where applicable. 
> Oleg or/and I, we can help when necessary and review your code.
> 
> Thanks,
> -Yuri
> 
> On Mon, Dec 03, 2007 at 08:25:42PM +0000, Dan Munckton wrote:
> > Hi Oleg
> > 
> > Thanks for your reply.
> > 
> > > am I right that your are going to fix our code so it correctly handled 
> > > situation when Xinerama is loaded but we have just one screen, so we 
> > > could use Xrandr extension in such configuration?
> > 
> > Yes. I'm happy to try and produce a patch if there's no-one else working
> > on this issue. My employer's product will soon be directly affected by
> > the problem so I'm very motivated to see it solved as soon as possible.
> > 
> > This would be my first contribution to Java/OpenJDK and therefore I may
> > not progress as quickly as others who are already involved. Is it true
> > that new contributors are assigned a mentor to assist a little?
> > 
> > > This code is somewhere on boundary of AWT and 2D areas so you may want 
> > > to also check with 2D.  As for AWT side I can say for sure that we do 
> > > not work on similar issue.
> > 
> > Hello 2d-dev, is there anyone aware of/working on this problem already?
> > (http://mail.openjdk.java.net/pipermail/awt-dev/2007-November/000109.html)
> > 
> > > 
> > >  > I've still not opened a bug on the Java bug database, do I need to do
> > >  > that to be tidy?
> > > 
> > > you are supposed to send a path with bug id, so it looks reasonable to 
> > > have one :)
> > 
> > I have now opened a bug which has been assigned an id. It's not yet
> > visible in the external database but here's the link anyway:
> > 
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
> > 
> > Thanks
> > 
> > Dan



From Ben.LOUD at baesystems.com  Wed Dec  5 01:13:42 2007
From: Ben.LOUD at baesystems.com (LOUD, Ben)
Date: Wed, 5 Dec 2007 11:43:42 +1030
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for
	theX11 pipeline?
In-Reply-To: <20071204151114.GA11334@mbuki-mvuki.org>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>

I'm not an expert, but I don't think Cairo would be appropriate for
OpenJDK, at least not as a complete Java2D implementation. Not that it
cant work, Classpath did just that quite successfully. But OpenJDK
already has a huge amount of a 2D stack implemented that they've
developed over many years including comprehensive and high quality
support for image rendering and transforming, compositing, color
mapping, text layout and rasterization etc. and its all high performing
and works great with OpenGL and D3D pipelines. 

As far as I can tell, Cairo only exposes a high level API (like Java2D)
so to use it, you would probably have to throw away all the existing
OpenJDK Java2D code in order to use it. That would be a real shame since
many would argue its the best in the business! (it's the main reason I
choose Java as my platform). Besides I don't think Cairo supports
anywhere near the number of image formats that Java2D does and its
hardware acceleration isnt yet in the same league. And if I remember
correctly, it doesn't support non-antialiased rendering. 

If there was anything in Cairo that Java2D could benefit from, it would
be just the part that does AA rasterizing of shapes in to tiles. But
factoring that out would probably be tricky. Besides, doing it ourselves
would be so much more fun :)

But if there are X11 drawing calls that can be replaced with XRender
then I'd be all for that! I know almost nothing about *nix graphics
technologies. Maybe someone can enlighten me on the details. It looks
like it can do compositing, image affine transforms, image convolution
(nice!), glyph caching and even linear and radial gradients. Does Java2D
not take advtange of any this yet? Sounds like a promising oppertunity.
But the only documentation I could find on it was sketchy. It looks like
it can make surfaces in VRAM and do compositing entirely in hardware. It
might then have potential to perform as well as OpenGL. Definitely worth
exploring! Go for it Clemens!

-----Original Message-----
From: 2d-dev-bounces at openjdk.java.net
[mailto:2d-dev-bounces at openjdk.java.net] On Behalf Of Jesse W. Hathaway
Sent: Wednesday, 5 December 2007 1:41 AM
To: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Best way organizing XRender additions for
theX11 pipeline?

> Hello,
> 
> I've some spare-time left so maybe I find some time to implement the
> most used software-fallbacks using XRender. There has been significant
> progress when it comes to XRender. With the EXA framework a few
> open-source drivers will soon be capable of accalerating fancy things,
> and nvidia has excellent XREnder accelaration in their latest binary
> driver.
> 
> I wonder what would be better:
> - Copy the source and implement an "XRender" pipeline replacing as
> much of X11 drawing functionality as possible.
> - Extend the existing one and let software-fallbacks there if no
> XRender is available.

Has creating a Cairo, cairographics.org, pipeline been considered? A 
Cairo pipeline would give you software fall backs as well as 
acceleration when available. Also given the increasing interest in 
using Cairo for X11 rendering its performance should only get better 
over time. Finally you could compare performance across Windows and
OSX since Cairo supports both platforms.

-Jesse
"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."




From cworth at cworth.org  Wed Dec  5 08:15:55 2007
From: cworth at cworth.org (Carl Worth)
Date: Wed, 05 Dec 2007 00:15:55 -0800
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions
	for	theX11 pipeline?
In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
Message-ID: <87odd5ftfo.wl%cworth@cworth.org>

On Wed, 5 Dec 2007 11:43:42 +1030, "LOUD, Ben" wrote:
> I'm not an expert, but I don't think Cairo would be appropriate for
> OpenJDK, at least not as a complete Java2D implementation.

I've been involved with the cairo implementation since the beginning,
(and even before that). I don't know a *lot* about Java2D but you're
probably quite right that there are likely to be things missing in
cairo that would be needed for a complete Java2D implementation.

> As far as I can tell, Cairo only exposes a high level API (like Java2D)
> so to use it, you would probably have to throw away all the existing
> OpenJDK Java2D code in order to use it.

I'm really not sure what that means exactly.

> But if there are X11 drawing calls that can be replaced with XRender
> then I'd be all for that! I know almost nothing about *nix graphics
> technologies. Maybe someone can enlighten me on the details. It looks
> like it can do compositing, image affine transforms, image convolution
> (nice!), glyph caching and even linear and radial gradients. Does Java2D
> not take advtange of any this yet? Sounds like a promising oppertunity.
> But the only documentation I could find on it was sketchy. It looks like
> it can make surfaces in VRAM and do compositing entirely in hardware. It
> might then have potential to perform as well as OpenGL. Definitely worth
> exploring! Go for it Clemens!

Yes, the X Render extension does support that list. And honestly, the
reason it isn't better documented is that we wrote cairo specifically
to be an easier-to-use interface for X Render functionality[*].

So if you do want to start using Render inside Java2D, (which seems
only a good thing when targeting an X server), the recommended
approach would be to use cairo to do that. This wouldn't mean that you
would have to use cairo to replace other existing non-X backends in
Java2D at all, of course.

If anyone is interested in exploring this further, I'd be more than
happy to answer any questions about cairo's functionality, how to use
it, or how it might be improved in the future.

Thanks,

-Carl

[*] Initial versions of cairo were strictly targeting X Render---the
capability of targeting Win32, Quartz, PostScript, PDF, SVG, OpenGL,
etc. all came much later.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071205/9432e9ba/attachment.bin>

From linuxhippy at gmail.com  Wed Dec  5 09:41:09 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Wed, 5 Dec 2007 10:41:09 +0100
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for
	theX11 pipeline?
In-Reply-To: <87odd5ftfo.wl%cworth@cworth.org>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
Message-ID: <194f62550712050141m50686712v3bed3f36b1215dbd@mail.gmail.com>

Hello,

> Yes, the X Render extension does support that list. And honestly, the
> reason it isn't better documented is that we wrote cairo specifically
> to be an easier-to-use interface for X Render functionality[*].
>
> So if you do want to start using Render inside Java2D, (which seems
> only a good thing when targeting an X server), the recommended
> approach would be to use cairo to do that. This wouldn't mean that you
> would have to use cairo to replace other existing non-X backends in
> Java2D at all, of course.
Despite the fact that cairo is a wonderful piece of software and its
great that we have it - I still don't see the advantage of using
cairo.
In Java2D/X11 everything is already there: the API, tesselation ... -
the only missing part are some rasterization fast-paths.

Do you know some documentation about Render, or some samples? Should I
look at Cairo's source?

Thanks, lg Clemens


From cworth at cworth.org  Wed Dec  5 09:59:33 2007
From: cworth at cworth.org (Carl Worth)
Date: Wed, 05 Dec 2007 01:59:33 -0800
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions for
	theX11 pipeline?
In-Reply-To: <194f62550712050141m50686712v3bed3f36b1215dbd@mail.gmail.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
	<194f62550712050141m50686712v3bed3f36b1215dbd@mail.gmail.com>
Message-ID: <87lk89fomy.wl%cworth@cworth.org>

On Wed, 5 Dec 2007 10:41:09 +0100, "Clemens Eisserer" wrote:
> Despite the fact that cairo is a wonderful piece of software and its
> great that we have it - I still don't see the advantage of using
> cairo.

If nothing else, it's much easier to use than Render's
interface. That's my only point for now.

> In Java2D/X11 everything is already there: the API, tesselation ... -
> the only missing part are some rasterization fast-paths.
>
> Do you know some documentation about Render, or some samples? Should I
> look at Cairo's source?

The only real documentation I know of is the Render protocol
specification, (which is what I used when I wrote the first
Render-using code in cairo). And cairo is the only real sample I
know. Do feel free to look at cairo's source to learn things, of
course.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071205/d4c554ce/attachment.bin>

From Ben.LOUD at baesystems.com  Wed Dec  5 11:18:36 2007
From: Ben.LOUD at baesystems.com (LOUD, Ben)
Date: Wed, 5 Dec 2007 21:48:36 +1030
Subject: [OpenJDK 2D-Dev] Best way organizing XRender additions
	for	theX11 pipeline?
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com><20071204151114.GA11334@mbuki-mvuki.org><755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>

Wow, Carl Worth himself! Great to see you on the list. Cairo no doubt is a wonderful package, a true gem of free software. All i meant by my "high level" comment was that its a complete top to bottom graphics package, when really the only part that OpenJDK desperately needs is one part of the pipeline, the part that rasterises paths to produce masks. OpenJDKs existing Java2D can do the rest (and do it very well) including compositing, text, transforms, color conversion etc. I couldnt see how Cairo could be made to work together with all of this existing code. 
 
Unless maybe if we implemented AATileGenerator to create an A8 Cairo image surfaces as tiles, and rasterize paths to those. Then Java2D can do the rest, including compositing to to X11/GDI/OGL/D3D/whatever. It just means we'd be be including Cairo for just a subset of its functionality. I'd be all for it though. Im sceptical that the pure Java Pices rasterizer that replaced Ductus could ever perform as well as we'd like. 
 
I wonder how difficult it would be to factor out Cairo's rasterisation and stroking code so we could just use that. We wouldnt need its compositng, font support, SVG and PDF backends etc. etc. Of course I know zero about Cairo's internals but if its feasible, it might be worth a look. I'd love to see it happen. 
 
I doubt we'd need cairo to take advantage of X Render though. That doesnt sound to me like the difficult part. I would think it would similar to what they've already done for OGL and D3D.
 
2D team, thoughts? Is X Render used at all or do you have any plans to use it? Do you think theres any potential for Cairo as a rasterizer if it were possible to isolate that code? 

________________________________

From: Carl Worth [mailto:cworth at cworth.org]
Sent: Wed 5/12/2007 6:45 PM
To: LOUD, Ben
Cc: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Best way organizing XRender additions for theX11 pipeline?



On Wed, 5 Dec 2007 11:43:42 +1030, "LOUD, Ben" wrote:
> I'm not an expert, but I don't think Cairo would be appropriate for
> OpenJDK, at least not as a complete Java2D implementation.

I've been involved with the cairo implementation since the beginning,
(and even before that). I don't know a *lot* about Java2D but you're
probably quite right that there are likely to be things missing in
cairo that would be needed for a complete Java2D implementation.

> As far as I can tell, Cairo only exposes a high level API (like Java2D)
> so to use it, you would probably have to throw away all the existing
> OpenJDK Java2D code in order to use it.

I'm really not sure what that means exactly.

> But if there are X11 drawing calls that can be replaced with XRender
> then I'd be all for that! I know almost nothing about *nix graphics
> technologies. Maybe someone can enlighten me on the details. It looks
> like it can do compositing, image affine transforms, image convolution
> (nice!), glyph caching and even linear and radial gradients. Does Java2D
> not take advtange of any this yet? Sounds like a promising oppertunity.
> But the only documentation I could find on it was sketchy. It looks like
> it can make surfaces in VRAM and do compositing entirely in hardware. It
> might then have potential to perform as well as OpenGL. Definitely worth
> exploring! Go for it Clemens!

Yes, the X Render extension does support that list. And honestly, the
reason it isn't better documented is that we wrote cairo specifically
to be an easier-to-use interface for X Render functionality[*].

So if you do want to start using Render inside Java2D, (which seems
only a good thing when targeting an X server), the recommended
approach would be to use cairo to do that. This wouldn't mean that you
would have to use cairo to replace other existing non-X backends in
Java2D at all, of course.

If anyone is interested in exploring this further, I'd be more than
happy to answer any questions about cairo's functionality, how to use
it, or how it might be improved in the future.

Thanks,

-Carl

[*] Initial versions of cairo were strictly targeting X Render---the
capability of targeting Win32, Quartz, PostScript, PDF, SVG, OpenGL,
etc. all came much later.


"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071205/97f01d01/attachment.html>

From cworth at cworth.org  Wed Dec  5 17:53:37 2007
From: cworth at cworth.org (Carl Worth)
Date: Wed, 05 Dec 2007 09:53:37 -0800
Subject: [OpenJDK 2D-Dev] Best way organizing XRender
	additions	for	theX11 pipeline?
In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
Message-ID: <87eje1f2ou.wl%cworth@cworth.org>

On Wed, 5 Dec 2007 21:48:36 +1030, "LOUD, Ben" wrote:
> Wow, Carl Worth himself! Great to see you on the list. Cairo no
> doubt is a wonderful package, a true gem of free software.

Blah, blah, blah...

> All i meant by my "high level" comment was that its a complete top
> to bottom graphics package, when really the only part that OpenJDK
> desperately needs is one part of the pipeline, the part that
> rasterises paths to produce masks.

I don't disagree that cairo is high-level and likely quite similar to
the existing OpenJDK Java2D interfaces.

But as for "rasterizing a path to produce a mask", that isn't an
operation that Render provides at all, and it's also not something
that is hidden in layers inside cairo. You can get at an efficient
means of doing that with Render by calling into existing cairo
interfaces just fine.

Meanwhile, if instead of "paths" you've actually already got something
tessellated and just need it to be rasterized, then sure, you can call
into XRenderCompositeTrapezoids to do just that if you'd like.

But note that there's a big difference between just calling
XRenderCompositeTrapezoids to get rasterization and using Render
efficiently. For one thing, as suggested by its name, that call can do
both rasterization and compositing, (potentially with accelerated
support from the graphics hardware), so you're not winning by using it
only or rasterization.

> I wonder how difficult it would be to factor out Cairo's
> rasterisation and stroking code so we could just use that. We
> wouldnt need its compositng, font support, SVG and PDF backends
> etc. etc. Of course I know zero about Cairo's internals but if its
> feasible, it might be worth a look. I'd love to see it happen.

Here, I'm totally lost. Things like the SVG and PDF backends are the
lightest things in cairo, (no dependencies at all, for example), so
they should be the least of your concerns. Meanwhile for
"rasterization and stroking" the _code_ that is in cairo---the
software implementation in pixman actually---isn't the most
interesting part. It's not the fastest rasterizer around, so you'd
be making a big mistake to do a bunch of work to try to extract
it. Instead, what is interesting about cairo's rasterization is the
interface to get at faster underlying systems. In the current
conversation you only care about one target (X Render) but as above,
calling into cairo for rasterization alone should work fine. There's
no need to factor anything out.

> I doubt we'd need cairo to take advantage of X Render though. That
> doesnt sound to me like the difficult part. I would think it would
> similar to what they've already done for OGL and D3D.

There are parts of using Render that are a fair amount of work. For
example, getting efficient text output through Render requires the
client to manage a server-side cache of glyph images, etc. Maybe
that's similar to what you've done for OGL and D3D as you say. But
there's not strictly any need to write new code for that. But don't
let me get in your way---please write whatever code you enjoy.

So I'm just trying to say that cairo exists, and should still work
well for the _original_ purpose of cairo, (provide a simple interface
for getting at X Render functionality), even if you just ignore
everything else that cairo can also do.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071205/a45f6032/attachment.bin>

From lists at munckfish.net  Wed Dec  5 22:54:07 2007
From: lists at munckfish.net (Dan Munckton)
Date: Wed, 05 Dec 2007 22:54:07 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode
	with	Xorg	server 1.3.0+ (I'm	ready to work on a patch)
In-Reply-To: <47547040.2070606@Sun.COM>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com> <1196713542.6134.16.camel@dylan>
	<47547040.2070606@Sun.COM>
Message-ID: <1196895247.6148.29.camel@dylan>

Hi Dmitri

Sorry about the delay in replying.

>    BTW, someone posted a hackish work around for this issue
>    (see 6636469).

Thank you, yes I saw that - same thing was posted to the Ubuntu bug.

>    As I mentioned in my evaluation (you should see it shortly *)
>    this bug is related to this one:
>       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6599351
> 
>    I think this should be addressed by two fixes:
>      1. we need to correctly detect whether Xinerama is present and
>         active (6599351)
>      2. as you suggested we should relax the requirement concerning
>         xinerama and randr (6636469)

Interesting. Although I hadn't tested with a multi-monitor setup it's no
surprise to me at all that there are other knock-on affects of the
changes in Xorg Server 1.3.

> 
>    The first part (arguably =) belongs to AWT and will need to work
>    correctly on both linux ans solaris (with newer Xorg servers).
> 
>    The second part belongs to 2D. I guess for the sake of simplicity
>    we could fold both issues into the same bug report since they both
>    have same underlying cause.
>    Typically we close the newer bug as a duplicate of the older one.
>    What do you think?

That's perfectly fine with me.

Cheers

Dan



From Ben.LOUD at baesystems.com  Wed Dec  5 23:16:17 2007
From: Ben.LOUD at baesystems.com (LOUD, Ben)
Date: Thu, 6 Dec 2007 09:46:17 +1030
Subject: [OpenJDK 2D-Dev] Best way organizing
	XRenderadditions	for	theX11 pipeline?
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com><20071204151114.GA11334@mbuki-mvuki.org><755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com><87odd5ftfo.wl%cworth@cworth.org><755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
	<87eje1f2ou.wl%cworth@cworth.org>
Message-ID: <755F5FA20B29364FBA287DB1BEBCE80A012CAF61@SBEMAIL1.au.baesystems.com>

>> Meanwhile, if instead of "paths" you've actually already got something
>> tessellated and just need it to be rasterized, then sure, you can call
>> into XRenderCompositeTrapezoids to do just that if you'd like.
 
ahh ok this is interesting. I see your point. I've been speaking under the assumption that X Render wouldnt be involved in this step. I believe in Java2D, all the work of producing coverage values is always done in software, and OGL or whatever only does the compositing. I hadnt considered that Render could accelerate both.

________________________________

From: 2d-dev-bounces at openjdk.java.net on behalf of Carl Worth
Sent: Thu 6/12/2007 4:23 AM
To: LOUD, Ben
Cc: 2d-dev at openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] Best way organizing XRenderadditions for theX11 pipeline?

On Wed, 5 Dec 2007 21:48:36 +1030, "LOUD, Ben" wrote:
> Wow, Carl Worth himself! Great to see you on the list. Cairo no
> doubt is a wonderful package, a true gem of free software.

Blah, blah, blah...

> All i meant by my "high level" comment was that its a complete top
> to bottom graphics package, when really the only part that OpenJDK
> desperately needs is one part of the pipeline, the part that
> rasterises paths to produce masks.

I don't disagree that cairo is high-level and likely quite similar to
the existing OpenJDK Java2D interfaces.

But as for "rasterizing a path to produce a mask", that isn't an
operation that Render provides at all, and it's also not something
that is hidden in layers inside cairo. You can get at an efficient
means of doing that with Render by calling into existing cairo
interfaces just fine.

Meanwhile, if instead of "paths" you've actually already got something
tessellated and just need it to be rasterized, then sure, you can call
into XRenderCompositeTrapezoids to do just that if you'd like.

But note that there's a big difference between just calling
XRenderCompositeTrapezoids to get rasterization and using Render
efficiently. For one thing, as suggested by its name, that call can do
both rasterization and compositing, (potentially with accelerated
support from the graphics hardware), so you're not winning by using it
only or rasterization.

> I wonder how difficult it would be to factor out Cairo's
> rasterisation and stroking code so we could just use that. We
> wouldnt need its compositng, font support, SVG and PDF backends
> etc. etc. Of course I know zero about Cairo's internals but if its
> feasible, it might be worth a look. I'd love to see it happen.

Here, I'm totally lost. Things like the SVG and PDF backends are the
lightest things in cairo, (no dependencies at all, for example), so
they should be the least of your concerns. Meanwhile for
"rasterization and stroking" the _code_ that is in cairo---the
software implementation in pixman actually---isn't the most
interesting part. It's not the fastest rasterizer around, so you'd
be making a big mistake to do a bunch of work to try to extract
it. Instead, what is interesting about cairo's rasterization is the
interface to get at faster underlying systems. In the current
conversation you only care about one target (X Render) but as above,
calling into cairo for rasterization alone should work fine. There's
no need to factor anything out.

> I doubt we'd need cairo to take advantage of X Render though. That
> doesnt sound to me like the difficult part. I would think it would
> similar to what they've already done for OGL and D3D.

There are parts of using Render that are a fair amount of work. For
example, getting efficient text output through Render requires the
client to manage a server-side cache of glyph images, etc. Maybe
that's similar to what you've done for OGL and D3D as you say. But
there's not strictly any need to write new code for that. But don't
let me get in your way---please write whatever code you enjoy.

So I'm just trying to say that cairo exists, and should still work
well for the _original_ purpose of cairo, (provide a simple interface
for getting at X Render functionality), even if you just ignore
everything else that cairo can also do.

-Carl

"Warning:
The information contained in this email and any attached files is
confidential to BAE Systems Australia. If you are not the intended
recipient, any use, disclosure or copying of this email or any
attachments is expressly prohibited.  If you have received this email
in error, please notify us immediately. VIRUS: Every care has been
taken to ensure this email and its attachments are virus free,
however, any loss or damage incurred in using this email is not the
sender's responsibility.  It is your responsibility to ensure virus
checks are completed before installing any data sent in this email to
your computer."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071206/4110438f/attachment.html>

From lists at munckfish.net  Wed Dec  5 23:25:13 2007
From: lists at munckfish.net (Dan Munckton)
Date: Wed, 05 Dec 2007 23:25:13 +0000
Subject: [OpenJDK 2D-Dev] <AWT Dev> Java Fullscreen Mode with
	Xorg	server 1.3.0+
In-Reply-To: <20071204131639.GA9128@frigate.russia.sun.com>
References: <1196246017.8431.23.camel@dylan> <1196455116.9594.7.camel@dylan>
	<4750C932.3090908@sun.com> <1196713542.6134.16.camel@dylan>
	<20071204131639.GA9128@frigate.russia.sun.com>
Message-ID: <1196897113.6148.58.camel@dylan>

Hi Yuri

> this new bug, 6599351, seems to be about the same issue, isn't it?
> It should be fixed in several releases, as I understand.

Yes it does appear that both bugs are side effects of the changes
happening in Xorg which Java now needs to accommodate. 

I have recreated my problem in Java versions 6 and 7. 

> Now let's decide: if you will create a patch for your bug then I'll not 
> work on my,  otherwise I'll start but not very fast, either.

I'll need to know more about the plans you have to fix 6599351 and also
gauge how big my fix is going to be. It may not be worth us both working
on this separately.

Currently I'm imagining the changes to be small to get fullscreen
working when there's only one monitor. But I still need to understand
more about what needs to happen when multiple monitors are attached.

> Anyway, after your patch is ready for jdk7, I can port it to earlier non-open releases
> where applicable. 

I understand new fixes have to mature through at least one Java 7 test
release cycle before they can be back-ported. Could you tell me when the
next Java 7 test build is due and how long the interval between them is?

How much time is there before the next Java 6 update? Would there be
enough time to get these fixes into that?

> Oleg or/and I, we can help when necessary and review your code.

That would be brilliant, thank you.

Cheers

Dan



From Dmitri.Trembovetski at Sun.COM  Fri Dec  7 19:17:32 2007
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 07 Dec 2007 11:17:32 -0800
Subject: [OpenJDK 2D-Dev] Best way
 organizing	XRenderadditions	for	theX11 pipeline?
In-Reply-To: <755F5FA20B29364FBA287DB1BEBCE80A012CAF61@SBEMAIL1.au.baesystems.com>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
	<87eje1f2ou.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF61@SBEMAIL1.au.baesystems.com>
Message-ID: <47599C4C.60302@Sun.COM>



LOUD, Ben wrote:
>  >> Meanwhile, if instead of "paths" you've actually already got something
>  >> tessellated and just need it to be rasterized, then sure, you can call
>  >> into XRenderCompositeTrapezoids to do just that if you'd like.
>  
> ahh ok this is interesting. I see your point. I've been speaking under 
> the assumption that X Render wouldnt be involved in this step. I believe 
> in Java2D, all the work of producing coverage values is always done in 
> software, and OGL or whatever only does the compositing. I hadnt 
> considered that Render could accelerate both.

   Yes indeed, in Java2D this part is done in software.
   However, I think that it would be nice to start out with
   just XRender pipeline (may be sitting on top of the
   x11 pipeline - the same way the old ddraw pipeline
   extends gdi one).
   I'm not really familiar with XRender myself so I don't
   know if you could mix X11 and Xrender rendering to
   the same drawable.

   I think we'll need something to address performance issues with
   apps using AA rendering and alpha compositing on X.
   We've been careful not to use too much of both in our
   built-in Swing L&Fs, but with the introductions of
   Nimbus that goes out of the window - it is fully vector
   graphics driven, with AA and AC everywhere.
   The performance on X11 will suck as a result of that,
   unfortunately.

   I have my doubts about fully integrating Cairo at this
   point (just because it would be much more extensive
   undertaking) but it should be relatively straightforward to
   implement an XRender pipeline.

   You can follow the example of x11 and opengl pipelnes.

   Unfortunately you don't have access to the new D3D
   and opengl pipelines which we're working on for
   6uN - we have improved code sharing between the pipelines
   (d3d, ogl) a lot, generalized a bunch of stuff, so it might have
   been easier to start from there.
   We could forward port the shared pieces to openjdk once
   we have some breathing time.

   Anyway, the I would approach this would be something like this.

   You'd need to create a SurfaceData subclass (say, XRSurfaceData) with
   appropriate SurfaceType. See OGL/GLXSurfaceData for
   the inspiration. Whether your surface type would be a subtype
   of X11* surface types depends on whether you can do x11
   rendering to XRender surfaces (Pictures?).

   Then you'd define the pipes and blits which render to
   and from your surfaces (see OGLRenderer, OGLBlitLoops).

   You'd need to create appropriate SurfaceManager (Volatile- and
   Caching-) so it would create surfaces of your type
   for Buffered- and Volatile-images, and BufferStrategy.
   (see GLXVolatileSurfaceManager). Also see SurfaceManagerFactory -
   this is where SurfaceManagers are created.

   Also, you'd need to create your own GraphicsConfiguration
   subclass (see GLXGraphicsConfig) so that the window surfaces
   of your type can be created.

   There's tons more details, of course. But this is a
   general direction.

   Thanks,
     Dmitri


> ------------------------------------------------------------------------
> *From:* 2d-dev-bounces at openjdk.java.net on behalf of Carl Worth
> *Sent:* Thu 6/12/2007 4:23 AM
> *To:* LOUD, Ben
> *Cc:* 2d-dev at openjdk.java.net
> *Subject:* Re: [OpenJDK 2D-Dev] Best way organizing XRenderadditions for 
> theX11 pipeline?
> 
> On Wed, 5 Dec 2007 21:48:36 +1030, "LOUD, Ben" wrote:
>  > Wow, Carl Worth himself! Great to see you on the list. Cairo no
>  > doubt is a wonderful package, a true gem of free software.
> 
> Blah, blah, blah...
> 
>  > All i meant by my "high level" comment was that its a complete top
>  > to bottom graphics package, when really the only part that OpenJDK
>  > desperately needs is one part of the pipeline, the part that
>  > rasterises paths to produce masks.
> 
> I don't disagree that cairo is high-level and likely quite similar to
> the existing OpenJDK Java2D interfaces.
> 
> But as for "rasterizing a path to produce a mask", that isn't an
> operation that Render provides at all, and it's also not something
> that is hidden in layers inside cairo. You can get at an efficient
> means of doing that with Render by calling into existing cairo
> interfaces just fine.
> 
> Meanwhile, if instead of "paths" you've actually already got something
> tessellated and just need it to be rasterized, then sure, you can call
> into XRenderCompositeTrapezoids to do just that if you'd like.
> 
> But note that there's a big difference between just calling
> XRenderCompositeTrapezoids to get rasterization and using Render
> efficiently. For one thing, as suggested by its name, that call can do
> both rasterization and compositing, (potentially with accelerated
> support from the graphics hardware), so you're not winning by using it
> only or rasterization.
> 
>  > I wonder how difficult it would be to factor out Cairo's
>  > rasterisation and stroking code so we could just use that. We
>  > wouldnt need its compositng, font support, SVG and PDF backends
>  > etc. etc. Of course I know zero about Cairo's internals but if its
>  > feasible, it might be worth a look. I'd love to see it happen.
> 
> Here, I'm totally lost. Things like the SVG and PDF backends are the
> lightest things in cairo, (no dependencies at all, for example), so
> they should be the least of your concerns. Meanwhile for
> "rasterization and stroking" the _code_ that is in cairo---the
> software implementation in pixman actually---isn't the most
> interesting part. It's not the fastest rasterizer around, so you'd
> be making a big mistake to do a bunch of work to try to extract
> it. Instead, what is interesting about cairo's rasterization is the
> interface to get at faster underlying systems. In the current
> conversation you only care about one target (X Render) but as above,
> calling into cairo for rasterization alone should work fine. There's
> no need to factor anything out.
> 
>  > I doubt we'd need cairo to take advantage of X Render though. That
>  > doesnt sound to me like the difficult part. I would think it would
>  > similar to what they've already done for OGL and D3D.
> 
> There are parts of using Render that are a fair amount of work. For
> example, getting efficient text output through Render requires the
> client to manage a server-side cache of glyph images, etc. Maybe
> that's similar to what you've done for OGL and D3D as you say. But
> there's not strictly any need to write new code for that. But don't
> let me get in your way---please write whatever code you enjoy.
> 
> So I'm just trying to say that cairo exists, and should still work
> well for the _original_ purpose of cairo, (provide a simple interface
> for getting at X Render functionality), even if you just ignore
> everything else that cairo can also do.
> 
> -Carl
> 
> "Warning:
> The information contained in this email and any attached files is
> confidential to BAE Systems Australia. If you are not the intended
> recipient, any use, disclosure or copying of this email or any
> attachments is expressly prohibited.  If you have received this email
> in error, please notify us immediately. VIRUS: Every care has been
> taken to ensure this email and its attachments are virus free,
> however, any loss or damage incurred in using this email is not the
> sender's responsibility.  It is your responsibility to ensure virus
> checks are completed before installing any data sent in this email to
> your computer."
> 


From Dmitri.Trembovetski at Sun.COM  Fri Dec  7 19:27:28 2007
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Fri, 07 Dec 2007 11:27:28 -0800
Subject: [OpenJDK 2D-Dev] Best way
 organizing	XRenderadditions	for	theX11 pipeline?
In-Reply-To: <47599C4C.60302@Sun.COM>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
	<87eje1f2ou.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF61@SBEMAIL1.au.baesystems.com>
	<47599C4C.60302@Sun.COM>
Message-ID: <47599EA0.3080907@Sun.COM>


   As a matter of fact, Chris Campbell from the 2D team
   did an initial investigation on XRender pipeline
   a while back (I just found an internal wiki page with
   the results of that investigation).

   I hope he doesn't mind me posting his thoughts here:
It doesn't appear that we can simply extend the existing X11Renderer code. XRender only knows how to fill rectangles, 
trapezoids, and triangles, so we'd have to do some restructuring so that we issue other types of primitives in terms of 
these operations. Probably need a complete rewrite of X11Renderer.

Also, XRender operations speak to a "Picture", which can be derived from an existing Drawable, so we'd need to somehow 
keep a reference to a Picture in the X11SDOps structure.

It appears that XRender operations are not affected by basic Xlib GC state (such as color, clip region, logic op, etc), 
so we'd need a separate state validation path in X11SurfaceData (or perhaps a subclass?) that handles things like 
setting the current clip region, composite op, etc.

The OpenGLPipeline deviates slightly from the ColorModel? spec in that it treats opaque destinations as premultiplied. 
(This is not allowable under the current ColorModel? spec, but so far no one has called us out on it. We were hoping to 
relax the spec in Mustang but we never go around to it unfortunately.) We will probably need to do something similar for 
this new pipeline, because we will be blending premultiplied components to an opaque destination.

A good place to start would be to try to implement MaskFill using XRender. We could cache a small (32x32) Picture in the 
PictStandardA8? format to use as the mask.

   And, we have a couple of bugs already filed for the
   use of XRender:
     * 6307603: [X11] Use RENDER extension for complex operations done in software
     * 5086814: RFE: Java 2D: consider Xrender for anti-aliased text on remote X11

   Thanks,
     Dmitri
   Java2D Team

Dmitri Trembovetski wrote:
> 
> 
> LOUD, Ben wrote:
>>  >> Meanwhile, if instead of "paths" you've actually already got 
>> something
>>  >> tessellated and just need it to be rasterized, then sure, you can 
>> call
>>  >> into XRenderCompositeTrapezoids to do just that if you'd like.
>>  
>> ahh ok this is interesting. I see your point. I've been speaking under 
>> the assumption that X Render wouldnt be involved in this step. I 
>> believe in Java2D, all the work of producing coverage values is always 
>> done in software, and OGL or whatever only does the compositing. I 
>> hadnt considered that Render could accelerate both.
> 
>   Yes indeed, in Java2D this part is done in software.
>   However, I think that it would be nice to start out with
>   just XRender pipeline (may be sitting on top of the
>   x11 pipeline - the same way the old ddraw pipeline
>   extends gdi one).
>   I'm not really familiar with XRender myself so I don't
>   know if you could mix X11 and Xrender rendering to
>   the same drawable.
> 
>   I think we'll need something to address performance issues with
>   apps using AA rendering and alpha compositing on X.
>   We've been careful not to use too much of both in our
>   built-in Swing L&Fs, but with the introductions of
>   Nimbus that goes out of the window - it is fully vector
>   graphics driven, with AA and AC everywhere.
>   The performance on X11 will suck as a result of that,
>   unfortunately.
> 
>   I have my doubts about fully integrating Cairo at this
>   point (just because it would be much more extensive
>   undertaking) but it should be relatively straightforward to
>   implement an XRender pipeline.
> 
>   You can follow the example of x11 and opengl pipelnes.
> 
>   Unfortunately you don't have access to the new D3D
>   and opengl pipelines which we're working on for
>   6uN - we have improved code sharing between the pipelines
>   (d3d, ogl) a lot, generalized a bunch of stuff, so it might have
>   been easier to start from there.
>   We could forward port the shared pieces to openjdk once
>   we have some breathing time.
> 
>   Anyway, the I would approach this would be something like this.
> 
>   You'd need to create a SurfaceData subclass (say, XRSurfaceData) with
>   appropriate SurfaceType. See OGL/GLXSurfaceData for
>   the inspiration. Whether your surface type would be a subtype
>   of X11* surface types depends on whether you can do x11
>   rendering to XRender surfaces (Pictures?).
> 
>   Then you'd define the pipes and blits which render to
>   and from your surfaces (see OGLRenderer, OGLBlitLoops).
> 
>   You'd need to create appropriate SurfaceManager (Volatile- and
>   Caching-) so it would create surfaces of your type
>   for Buffered- and Volatile-images, and BufferStrategy.
>   (see GLXVolatileSurfaceManager). Also see SurfaceManagerFactory -
>   this is where SurfaceManagers are created.
> 
>   Also, you'd need to create your own GraphicsConfiguration
>   subclass (see GLXGraphicsConfig) so that the window surfaces
>   of your type can be created.
> 
>   There's tons more details, of course. But this is a
>   general direction.
> 
>   Thanks,
>     Dmitri
> 
> 
>> ------------------------------------------------------------------------
>> *From:* 2d-dev-bounces at openjdk.java.net on behalf of Carl Worth
>> *Sent:* Thu 6/12/2007 4:23 AM
>> *To:* LOUD, Ben
>> *Cc:* 2d-dev at openjdk.java.net
>> *Subject:* Re: [OpenJDK 2D-Dev] Best way organizing XRenderadditions 
>> for theX11 pipeline?
>>
>> On Wed, 5 Dec 2007 21:48:36 +1030, "LOUD, Ben" wrote:
>>  > Wow, Carl Worth himself! Great to see you on the list. Cairo no
>>  > doubt is a wonderful package, a true gem of free software.
>>
>> Blah, blah, blah...
>>
>>  > All i meant by my "high level" comment was that its a complete top
>>  > to bottom graphics package, when really the only part that OpenJDK
>>  > desperately needs is one part of the pipeline, the part that
>>  > rasterises paths to produce masks.
>>
>> I don't disagree that cairo is high-level and likely quite similar to
>> the existing OpenJDK Java2D interfaces.
>>
>> But as for "rasterizing a path to produce a mask", that isn't an
>> operation that Render provides at all, and it's also not something
>> that is hidden in layers inside cairo. You can get at an efficient
>> means of doing that with Render by calling into existing cairo
>> interfaces just fine.
>>
>> Meanwhile, if instead of "paths" you've actually already got something
>> tessellated and just need it to be rasterized, then sure, you can call
>> into XRenderCompositeTrapezoids to do just that if you'd like.
>>
>> But note that there's a big difference between just calling
>> XRenderCompositeTrapezoids to get rasterization and using Render
>> efficiently. For one thing, as suggested by its name, that call can do
>> both rasterization and compositing, (potentially with accelerated
>> support from the graphics hardware), so you're not winning by using it
>> only or rasterization.
>>
>>  > I wonder how difficult it would be to factor out Cairo's
>>  > rasterisation and stroking code so we could just use that. We
>>  > wouldnt need its compositng, font support, SVG and PDF backends
>>  > etc. etc. Of course I know zero about Cairo's internals but if its
>>  > feasible, it might be worth a look. I'd love to see it happen.
>>
>> Here, I'm totally lost. Things like the SVG and PDF backends are the
>> lightest things in cairo, (no dependencies at all, for example), so
>> they should be the least of your concerns. Meanwhile for
>> "rasterization and stroking" the _code_ that is in cairo---the
>> software implementation in pixman actually---isn't the most
>> interesting part. It's not the fastest rasterizer around, so you'd
>> be making a big mistake to do a bunch of work to try to extract
>> it. Instead, what is interesting about cairo's rasterization is the
>> interface to get at faster underlying systems. In the current
>> conversation you only care about one target (X Render) but as above,
>> calling into cairo for rasterization alone should work fine. There's
>> no need to factor anything out.
>>
>>  > I doubt we'd need cairo to take advantage of X Render though. That
>>  > doesnt sound to me like the difficult part. I would think it would
>>  > similar to what they've already done for OGL and D3D.
>>
>> There are parts of using Render that are a fair amount of work. For
>> example, getting efficient text output through Render requires the
>> client to manage a server-side cache of glyph images, etc. Maybe
>> that's similar to what you've done for OGL and D3D as you say. But
>> there's not strictly any need to write new code for that. But don't
>> let me get in your way---please write whatever code you enjoy.
>>
>> So I'm just trying to say that cairo exists, and should still work
>> well for the _original_ purpose of cairo, (provide a simple interface
>> for getting at X Render functionality), even if you just ignore
>> everything else that cairo can also do.
>>
>> -Carl
>>
>> "Warning:
>> The information contained in this email and any attached files is
>> confidential to BAE Systems Australia. If you are not the intended
>> recipient, any use, disclosure or copying of this email or any
>> attachments is expressly prohibited.  If you have received this email
>> in error, please notify us immediately. VIRUS: Every care has been
>> taken to ensure this email and its attachments are virus free,
>> however, any loss or damage incurred in using this email is not the
>> sender's responsibility.  It is your responsibility to ensure virus
>> checks are completed before installing any data sent in this email to
>> your computer."
>>


From lists at munckfish.net  Sat Dec  8 13:43:36 2007
From: lists at munckfish.net (Dan Munckton)
Date: Sat, 08 Dec 2007 13:43:36 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive Mode
	not working with	Xorg server 1.3.0 and above
Message-ID: <1197121416.14405.50.camel@dylan>

Hi Oleg, Dmitry, Yuri, all

Please find attached my first attempt at fixing bug 6636469 [0].


APPROACH

The fix is really simple it just checks to make sure RANDR's version is
1.2 or greater if usingXinerama is true, if this is all fine it proceeds
to load the libXrandr funcs.

For the moment I've completely ignored 6599351, and not touched any of
the Xinerama loading code at all. 

BTW I note that with 6599351 the user has an old style X dual-head
config without using Xinerama - I found a note on the Debian Xrandr1.2
Howto wiki page [1] explaining that this configuration should crash
Xserver 1.3. Does it behave differently in Solaris X?


TESTING

The equipment I have here will allow me to test single monitor setups
with X servers 1.2 and 1.3. Java now behaves as expected in the
following cases:

1) Xserver 1.2 + 1 monitor + Xrandr
	Expect: isFullScreenSupported: true
	Result: PASS

2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
load but Xrandr and DRI won't load either)
	Expect: isFullScreenSupported: false
	Result: PASS

3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
	Expect: isFullScreenSupported: true
	Result: PASS

4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
load but Xrandr and DRI won't load either)
	Expect: isFullScreenSupported: false
	Result: PASS


TESTING TODO

I have an external LCD monitor at work which I can hook up to my laptop
next week. This should allow me to test out Xrandr 1.2 multi-monitor
setups. I'll post results as soon as complete.

However I don't think I can test out Xinerama dual head configs. I tried
to set this up once before but failed - I'm still not 100% certain if
Xinerama is actually compiled into my X server I will need to check this
out properly. 

If anyone here has a multi monitor setup already and would be prepared
to help me test the following scenarios I'd be very grateful.

5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
	Expect: isFullScreenSupported: false

6) Xserver 1.3 + 2 monitors + Xinerama
	Expect: isFullScreenSupported: false

I am also still to run the jtreg tests against this. I will come back
with results.

Also, do I need to mail both awt-dev and 2d-dev or will just one do in
future?

Cheers

Dan


[0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
[1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6636469_first_attempt.diff
Type: text/x-patch
Size: 2917 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20071208/a2ca4740/6636469_first_attempt.diff>

From linuxhippy at gmail.com  Sat Dec  8 17:26:16 2007
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 8 Dec 2007 18:26:16 +0100
Subject: [OpenJDK 2D-Dev] Best way organizing XRenderadditions for
	theX11 pipeline?
In-Reply-To: <47599EA0.3080907@Sun.COM>
References: <194f62550712040655t1bb89bf6g5a4892d394b7f86f@mail.gmail.com>
	<20071204151114.GA11334@mbuki-mvuki.org>
	<755F5FA20B29364FBA287DB1BEBCE80A037C31C9@SBEMAIL1.au.baesystems.com>
	<87odd5ftfo.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF60@SBEMAIL1.au.baesystems.com>
	<87eje1f2ou.wl%cworth@cworth.org>
	<755F5FA20B29364FBA287DB1BEBCE80A012CAF61@SBEMAIL1.au.baesystems.com>
	<47599C4C.60302@Sun.COM> <47599EA0.3080907@Sun.COM>
Message-ID: <194f62550712080926u1dadd8ffse610d505a6aef047@mail.gmail.com>

Hello Dmitri,

... and thanks a lot for the large amount of information.

I think I will try to implement XRender "fast-paths" for the most
common cases, instead of "forking" the pipeline. I hope it can be done
to not replace the X11 pipeline but rather extend it, as you mentioned
like GDI and DDraw.

Yes, I also think that a rewrite of the X11 pipeline very much in the
style of the OGL/D3D pipelines would be great - even the source
available in jdk7 is much cleaner and than the source of the X11
pipeline.
A complete rewrite of the X11 pipeline would be way too much work for
me, I have quite a hard time at university - I guess it would be
better to get at least something working than an unfinished project
somewhere on sourceforge ;)

I'll play arround a bit with it, hope the amount of questions will
nobody bother ;)

Thanks, lg Clemens


From Phil.Race at Sun.COM  Sat Dec  8 20:05:40 2007
From: Phil.Race at Sun.COM (Phil Race)
Date: Sat, 08 Dec 2007 12:05:40 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive
 Mode not working with	Xorg server 1.3.0 and above
In-Reply-To: <1197121416.14405.50.camel@dylan>
References: <1197121416.14405.50.camel@dylan>
Message-ID: <475AF914.1090309@sun.com>

Dan,
We can't take this fix as you have not signed the SCA and your name does not
appear here : https://sca.dev.java.net/CA_signatories.htm#m

-phil

Dan Munckton wrote:
> Hi Oleg, Dmitry, Yuri, all
>
> Please find attached my first attempt at fixing bug 6636469 [0].
>
>
> APPROACH
>
> The fix is really simple it just checks to make sure RANDR's version is
> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
> to load the libXrandr funcs.
>
> For the moment I've completely ignored 6599351, and not touched any of
> the Xinerama loading code at all. 
>
> BTW I note that with 6599351 the user has an old style X dual-head
> config without using Xinerama - I found a note on the Debian Xrandr1.2
> Howto wiki page [1] explaining that this configuration should crash
> Xserver 1.3. Does it behave differently in Solaris X?
>
>
> TESTING
>
> The equipment I have here will allow me to test single monitor setups
> with X servers 1.2 and 1.3. Java now behaves as expected in the
> following cases:
>
> 1) Xserver 1.2 + 1 monitor + Xrandr
> 	Expect: isFullScreenSupported: true
> 	Result: PASS
>
> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
> load but Xrandr and DRI won't load either)
> 	Expect: isFullScreenSupported: false
> 	Result: PASS
>
> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
> 	Expect: isFullScreenSupported: true
> 	Result: PASS
>
> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
> load but Xrandr and DRI won't load either)
> 	Expect: isFullScreenSupported: false
> 	Result: PASS
>
>
> TESTING TODO
>
> I have an external LCD monitor at work which I can hook up to my laptop
> next week. This should allow me to test out Xrandr 1.2 multi-monitor
> setups. I'll post results as soon as complete.
>
> However I don't think I can test out Xinerama dual head configs. I tried
> to set this up once before but failed - I'm still not 100% certain if
> Xinerama is actually compiled into my X server I will need to check this
> out properly. 
>
> If anyone here has a multi monitor setup already and would be prepared
> to help me test the following scenarios I'd be very grateful.
>
> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
> 	Expect: isFullScreenSupported: false
>
> 6) Xserver 1.3 + 2 monitors + Xinerama
> 	Expect: isFullScreenSupported: false
>
> I am also still to run the jtreg tests against this. I will come back
> with results.
>
> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
> future?
>
> Cheers
>
> Dan
>
>
> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>   
> ------------------------------------------------------------------------
>
> diff -r 99a06bc7fdb5 -r 7e529c4088cc src/solaris/native/sun/awt/awt_GraphicsEnv.c
> --- a/src/solaris/native/sun/awt/awt_GraphicsEnv.c	Tue Dec 04 16:28:33 2007 -0800
> +++ b/src/solaris/native/sun/awt/awt_GraphicsEnv.c	Sat Dec 08 13:29:25 2007 +0000
> @@ -1626,6 +1626,8 @@ Java_sun_awt_X11GraphicsEnvironment_getX
>  
>  #define BIT_DEPTH_MULTI java_awt_DisplayMode_BIT_DEPTH_MULTI
>  
> +typedef Status
> +    (*XRRQueryVersionType) (Display *dpy, int *major_versionp, int *minor_versionp);
>  typedef XRRScreenConfiguration*
>      (*XRRGetScreenInfoType)(Display *dpy, Drawable root);
>  typedef void
> @@ -1650,6 +1652,7 @@ typedef Status
>                                       short rate,
>                                       Time timestamp);
>  
> +static XRRQueryVersionType               awt_XRRQueryVersion;
>  static XRRGetScreenInfoType              awt_XRRGetScreenInfo;
>  static XRRFreeScreenConfigInfoType       awt_XRRFreeScreenConfigInfo;
>  static XRRConfigRatesType                awt_XRRConfigRates;
> @@ -1672,11 +1675,37 @@ static jboolean
>  static jboolean
>  X11GD_InitXrandrFuncs(JNIEnv *env)
>  {
> +    int rr_maj_ver = 0, rr_min_ver = 0;
> +
>      void *pLibRandR = dlopen("libXrandr.so.2", RTLD_LAZY | RTLD_LOCAL);
>      if (pLibRandR == NULL) {
>          J2dRlsTraceLn(J2D_TRACE_ERROR,
>                        "X11GD_InitXrandrFuncs: Could not open libXrandr.so.2");
>          return JNI_FALSE;
> +    }
> +
> +    LOAD_XRANDR_FUNC(XRRQueryVersion);
> +
> +    if (!(*awt_XRRQueryVersion)(awt_display, &rr_maj_ver, &rr_min_ver)) {
> +        J2dRlsTraceLn(J2D_TRACE_ERROR, 
> +                    "X11GD_InitXrandrFuncs: XRRQueryVersion returned an error status");
> +        dlclose(pLibRandR);
> +        return JNI_FALSE;
> +    }
> +
> +    if (usingXinerama) {
> +        /* 
> +         * We can proceed as long as this is RANDR 1.2 
> +         * As of Xorg server 1.3 onwards the Xinerama backend may actually be
> +         * a fake one provided by RANDR itself. See Java bug 6636469 for info.
> +         */
> +        if (!(rr_maj_ver >= 1 && rr_min_ver >= 2)) {
> +            J2dRlsTraceLn2(J2D_TRACE_INFO, "X11GD_InitXrandrFuncs: Can't use Xrandr. " 
> +                        "Xinerama is active and Xrandr version is %d.%d",
> +                        rr_maj_ver, rr_min_ver);
> +            dlclose(pLibRandR);
> +            return JNI_FALSE;
> +        }
>      }
>  
>      LOAD_XRANDR_FUNC(XRRGetScreenInfo);
> @@ -1814,15 +1843,6 @@ Java_sun_awt_X11GraphicsDevice_initXrand
>      int opcode = 0, firstEvent = 0, firstError = 0;
>      jboolean ret;
>  
> -    if (usingXinerama) {
> -        /*
> -         * REMIND: we'll just punt if Xinerama is enabled; we can remove this
> -         * restriction in the future if we find Xinerama and XRandR playing
> -         * well together...
> -         */
> -        return JNI_FALSE;
> -    }
> -
>      AWT_LOCK();
>      ret = (jboolean)XQueryExtension(awt_display, "RANDR",
>                                      &opcode, &firstEvent, &firstError);
>   



From lists at munckfish.net  Tue Dec 11 10:34:38 2007
From: lists at munckfish.net (Dan Munckton)
Date: Tue, 11 Dec 2007 10:34:38 +0000
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen
	Exclusive	Mode not working with	Xorg server 1.3.0 and above
In-Reply-To: <475AF914.1090309@sun.com>
References: <1197121416.14405.50.camel@dylan>  <475AF914.1090309@sun.com>
Message-ID: <1197369278.7494.8.camel@dylan>

Hi

> We can't take this fix as you have not signed the SCA and your name does not
> appear here : https://sca.dev.java.net/CA_signatories.htm#m

Just emailed in my signed SCA doc.

Thanks

Dan



From Dmitri.Trembovetski at Sun.COM  Wed Dec 19 23:57:56 2007
From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski)
Date: Wed, 19 Dec 2007 15:57:56 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 6636469: Java Fullscreen Exclusive
 Mode not working with	Xorg server 1.3.0 and above
In-Reply-To: <1197121416.14405.50.camel@dylan>
References: <1197121416.14405.50.camel@dylan>
Message-ID: <4769B004.10308@Sun.COM>


   Hi Dan,

   I know that you sent your SCA (repeatedly =) so
   I looked at the fix.

   It looks good.

   Please see my comments below.

Dan Munckton wrote:
> APPROACH
> 
> The fix is really simple it just checks to make sure RANDR's version is
> 1.2 or greater if usingXinerama is true, if this is all fine it proceeds
> to load the libXrandr funcs.

   Sounds good.

> For the moment I've completely ignored 6599351, and not touched any of
> the Xinerama loading code at all. 

   OK, I think it's a good idea to separate the two fixes.

> BTW I note that with 6599351 the user has an old style X dual-head
> config without using Xinerama - I found a note on the Debian Xrandr1.2
> Howto wiki page [1] explaining that this configuration should crash
> Xserver 1.3. Does it behave differently in Solaris X?

   You mean, if randr is present?
   It could be that it didn't have randr extension.
   It looks from the comments in the bug report that 1.3 works
   fine with dual screens w/o xinerama in general.

> TESTING
> 
> The equipment I have here will allow me to test single monitor setups
> with X servers 1.2 and 1.3. Java now behaves as expected in the
> following cases:
> 
> 1) Xserver 1.2 + 1 monitor + Xrandr
> 	Expect: isFullScreenSupported: true
> 	Result: PASS
> 
> 2) Xserver 1.2 + 1 monitor + Xinerama enabled (Xinerama won't actually
> load but Xrandr and DRI won't load either)
> 	Expect: isFullScreenSupported: false
> 	Result: PASS
> 
> 3) Xserver 1.3 + 1 monitor + Xrandr + fake Xinerama
> 	Expect: isFullScreenSupported: true
> 	Result: PASS
> 
> 4) Xserver 1.3 + 1 monitor + Xinerama enabled (Xinerama won't actually
> load but Xrandr and DRI won't load either)
> 	Expect: isFullScreenSupported: false
> 	Result: PASS

   I assume this is all on linux, right?

> TESTING TODO
> 
> I have an external LCD monitor at work which I can hook up to my laptop
> next week. This should allow me to test out Xrandr 1.2 multi-monitor
> setups. I'll post results as soon as complete.
> 
> However I don't think I can test out Xinerama dual head configs. I tried
> to set this up once before but failed - I'm still not 100% certain if
> Xinerama is actually compiled into my X server I will need to check this
> out properly. 
> 
> If anyone here has a multi monitor setup already and would be prepared
> to help me test the following scenarios I'd be very grateful.
> 
> 5) Xserver 1.2 + 2 monitor + Xinerama (Xrandr and DRI won't load)
> 	Expect: isFullScreenSupported: false
> 
> 6) Xserver 1.3 + 2 monitors + Xinerama
> 	Expect: isFullScreenSupported: false

   Ugh. That might be a problem - we don't have too many
   multiscreen solaris or linux systems that we could install
   new X server on. But we'll see what we can do.

   We can at least test on the configuration we have.
   I have a Solaris 10 machine with dual (non-xinerama)
   screen - the fs mode isn't supported on it.

> I am also still to run the jtreg tests against this. I will come back
> with results.

   I can't think of a good automated regression test for this fix.
   You can I suppose write a jtreg regression test as script
   (it is allowed), run xdpyinfo and find out that randr of the
   correct version is installed and then test if fullscreen
   is supported but it may not necessarily be a fully correct test -
   fullscreen may not be enabled for other reasons.

> Also, do I need to mail both awt-dev and 2d-dev or will just one do in
> future?

   This particular fix is 2D only, so we can continue on 2d-dev.
   The other one - we'll see. I suppose it's not that much of a problem
   if you cc both lists.

   Thanks,
     Dmitri


> 
> Cheers
> 
> Dan
> 
> 
> [0] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636469
> [1] Section VI.3 of http://wiki.debian.org/XStrikeForce/HowToRandR12
>