From xerxes at zafena.se Thu Dec 10 07:06:12 2009 From: xerxes at zafena.se (Xerxes Ranby) Date: Thu, 10 Dec 2009 16:06:12 +0100 Subject: Port of jules 0.0.1 to Icedtea7, and first impression when running on ARM. Message-ID: <4B210E64.80007@zafena.se> Hi I had some fun trying to get Jules working with the current Icedtea7 trunk. http://linuxhippy.blogspot.com/2009/11/jules-cairo-binding-001-release.html Getting jules to build was quite easy. I had to configure icedtea7 with --disable-xrender so that it skips to patch openjdk with the xrender patches currently bundled with icedtea and then manually patched the openjdk/jdk source dir with the webrev patch from the jules-0.0.1 release, I was delighted to see that the jules patch applied cleanly. The rest of the build went smooth. In order to get Jules 0.0.1 integrated into icedtea7 the file paths in the jules webrew patch needs a slight adjust to be openjdk relative instead of jdk relative so the patch can be applied directly on the openjdk tree like other icedtea patches and the old xrender patches. I hit some issues when running openjdk with the jules renderer on my ARM PC-Z1, see the attached images, basically all menus are empty of typefaces and no vector graphics are dawn at all. the only things that seems to be drawn ok where gray panels and some images. Images gets funny though when the frame are redrawn after being overlapped by a window, see the green glitches in the jules-xrender-arm-redraw-glitch.png . I beleve these issues are related to the cairo compilation when making libjules.so, during the compilation these messages got displayed that seems relevant: cairo (version 1.9.2 [snapshot]) will be compiled with: The following surface backends: Image: yes (always builtin) Xlib: no (disabled, use --enable-xlib to enable) Xlib Xrender: no (disabled, use --enable-xlib-xrender to enable) Quartz: no (requires CoreGraphics framework) Quartz-image: no (disabled, use --enable-quartz-image to enable) XCB: no (disabled, use --enable-xcb to enable) Win32: no (requires a Win32 platform) OS2: no (disabled, use --enable-os2 to enable) CairoScript: no (disabled, use --enable-script to enable) PostScript: no (disabled, use --enable-ps to enable) PDF: no (disabled, use --enable-pdf to enable) SVG: no (disabled, use --enable-svg to enable) glitz: no (disabled, use --enable-glitz to enable) BeOS: no (disabled, use --enable-beos to enable) DirectFB: no (disabled, use --enable-directfb to enable) The following font backends: User: yes (always builtin) FreeType: no (disabled, use --enable-ft to enable) Fontconfig: no (disabled, use --enable-fc to enable) Win32: no (requires a Win32 platform) Quartz: no (requires CoreGraphics framework) The following functions: PNG functions: no (disabled, use --enable-png to enable) And the following internal features: gtk-doc: no gcov support: no test surfaces: no (disabled, use --enable-test-surfaces to enable) ps testing: no pdf testing: no svg testing: no +++ It is strictly recommended that you do NOT disable the PNG functions +++ feature. +++ It is strictly recommended that you do NOT disable the PostScript surface +++ backend feature. +++ It is strictly recommended that you do NOT disable the PDF surface +++ backend feature. +++ It is strictly recommended that you do NOT disable the SVG surface +++ backend feature. *** It is strictly recommended that you enable the native surface backend *** feature for your platform. *** It is strictly recommended that you enable the native font backend *** feature for your platform. I also noticed that libjules.so can be compiled in combination with pixman 0.13 instead of 0.15 by simply lower the requirements during configure. Cheers, and have a great day! Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: jules-xrender-arm-redraw-glitch.png Type: image/png Size: 6818 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/xrender-dev/attachments/20091210/facca781/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: pc-z1-jules.png Type: image/png Size: 29531 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/xrender-dev/attachments/20091210/facca781/attachment-0003.png From gnu_andrew at member.fsf.org Thu Dec 10 07:09:44 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 10 Dec 2009 15:09:44 +0000 Subject: Port of jules 0.0.1 to Icedtea7, and first impression when running on ARM. In-Reply-To: <4B210E64.80007@zafena.se> References: <4B210E64.80007@zafena.se> Message-ID: <17c6771e0912100709r579f662an8915d3de7f8ac1e8@mail.gmail.com> 2009/12/10 Xerxes Ranby : > Hi > > I had some fun trying to get Jules working with the current Icedtea7 trunk. > http://linuxhippy.blogspot.com/2009/11/jules-cairo-binding-001-release.html > > Getting jules to build was quite easy. I had to configure icedtea7 with > --disable-xrender so that ?it skips to patch openjdk with the xrender > patches currently bundled with icedtea and then manually patched the > openjdk/jdk source dir with the webrev patch from the jules-0.0.1 > release, I was delighted to see that the jules patch applied cleanly. > The rest of the build went smooth. > > In order to get Jules 0.0.1 integrated into icedtea7 the file paths in the > jules ?webrew patch needs a slight adjust to be openjdk relative instead of > jdk ?relative so the patch can be applied directly on the openjdk tree like > ?other icedtea patches and the old xrender patches. > > I hit some issues when running openjdk with the jules renderer on my ARM > PC-Z1, see the attached ?images, basically all menus are empty of typefaces > and no vector graphics are dawn at all. ?the only things that seems to be > drawn ok where gray panels and some images. Images gets funny though when > the frame are redrawn after being overlapped by a window, see the green > glitches in the jules-xrender-arm-redraw-glitch.png . > > I beleve these issues are related to the cairo compilation when making > libjules.so, during the compilation these messages got displayed that > seems relevant: > cairo (version 1.9.2 [snapshot]) will be compiled with: > > The following surface backends: > ?Image: ? ? ? ? yes (always builtin) > ?Xlib: ? ? ? ? ?no (disabled, use --enable-xlib to enable) > ?Xlib Xrender: ?no (disabled, use --enable-xlib-xrender to enable) > ?Quartz: ? ? ? ?no (requires CoreGraphics framework) > ?Quartz-image: ?no (disabled, use --enable-quartz-image to enable) > ?XCB: ? ? ? ? ? no (disabled, use --enable-xcb to enable) > ?Win32: ? ? ? ? no (requires a Win32 platform) > ?OS2: ? ? ? ? ? no (disabled, use --enable-os2 to enable) > ?CairoScript: ? no (disabled, use --enable-script to enable) > ?PostScript: ? ?no (disabled, use --enable-ps to enable) > ?PDF: ? ? ? ? ? no (disabled, use --enable-pdf to enable) > ?SVG: ? ? ? ? ? no (disabled, use --enable-svg to enable) > ?glitz: ? ? ? ? no (disabled, use --enable-glitz to enable) > ?BeOS: ? ? ? ? ?no (disabled, use --enable-beos to enable) > ?DirectFB: ? ? ?no (disabled, use --enable-directfb to enable) > > The following font backends: > ?User: ? ? ? ? ?yes (always builtin) > ?FreeType: ? ? ?no (disabled, use --enable-ft to enable) > ?Fontconfig: ? ?no (disabled, use --enable-fc to enable) > ?Win32: ? ? ? ? no (requires a Win32 platform) > ?Quartz: ? ? ? ?no (requires CoreGraphics framework) > > The following functions: > ?PNG functions: no (disabled, use --enable-png to enable) > > And the following internal features: > ?gtk-doc: ? ? ? no > ?gcov support: ?no > ?test surfaces: no (disabled, use --enable-test-surfaces to enable) > ?ps testing: ? ?no > ?pdf testing: ? no > ?svg testing: ? no > > > +++ It is strictly recommended that you do NOT disable the PNG functions > +++ feature. > > +++ It is strictly recommended that you do NOT disable the PostScript > surface > +++ backend feature. > > +++ It is strictly recommended that you do NOT disable the PDF surface > +++ backend feature. > > +++ It is strictly recommended that you do NOT disable the SVG surface > +++ backend feature. > > *** It is strictly recommended that you enable the native surface backend > *** feature for your platform. > > *** It is strictly recommended that you enable the native font backend > *** feature for your platform. > > I also noticed that libjules.so can be compiled in combination with pixman > 0.13 instead of 0.15 by simply lower the requirements during configure. > > Cheers, and have a great day! > Xerxes > An even easier way is to check out the IcedTea forest: hg fclone -r icedtea-1.12 http://hg.openjdk.java.net/icedtea/jdk7 apply the patch from Clemens to that as-is, and then build IcedTea7 against it with --with-openjdk-src-dir. That's how I do all my testing. I don't mess around with creating IcedTea patches any more unless it's unavoidable. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From linuxhippy at gmail.com Thu Dec 10 11:11:37 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Thu, 10 Dec 2009 14:11:37 -0500 Subject: Port of jules 0.0.1 to Icedtea7, and first impression when running on ARM. In-Reply-To: <4B210E64.80007@zafena.se> References: <4B210E64.80007@zafena.se> Message-ID: <194f62550912101111o231ecb3td357469e871dc89a@mail.gmail.com> Hi Xerxes, Thanks a lot for testing :) > I hit some issues when running openjdk with the jules renderer on my ARM > PC-Z1, see the attached ?images, basically all menus are empty of typefaces > and no vector graphics are dawn at all. ?the only things that seems to be > drawn ok where gray panels and some images. Images gets funny though when > the frame are redrawn after being overlapped by a window, see the green > glitches in the jules-xrender-arm-redraw-glitch.png . Outch, that looks really bad. Even stuff where jules isn't involved seems to fail. I guess there are some problems in the new xrender pipeline :-/ To be honest I don't have a clue what is going wrong here, maybe some structure-alignment assumptions are not valid on arm. However except for font-rendering most things aren't that ugly, I can't imagine what would cause problem. On the other hand, I've just bought a 4GB SD card for my N800 and I've plenty of spare time during holidays now :) Just to be curious, does -Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine -Dsun.java2d.xrender=false work for more complex things like Java2Demo? > I beleve these issues are related to the cairo compilation when making > libjules.so, during the compilation these messages got displayed that > seems relevant: The warnings are expected, because cairo is built with a configuration thats not quite useful for daily purpose ;) > I also noticed that libjules.so can be compiled in combination with pixman > 0.13 instead of 0.15 by simply lower the requirements during configure. Thanks, good to know. Thanks again, and have a great day too :) - Clemens From xerxes at zafena.se Fri Dec 11 02:06:36 2009 From: xerxes at zafena.se (=?UTF-8?B?WGVyeGVzIFLDpW5ieQ==?=) Date: Fri, 11 Dec 2009 11:06:36 +0100 Subject: Port of jules 0.0.1 to Icedtea7, and first impression when running on ARM. In-Reply-To: <194f62550912101111o231ecb3td357469e871dc89a@mail.gmail.com> References: <4B210E64.80007@zafena.se> <194f62550912101111o231ecb3td357469e871dc89a@mail.gmail.com> Message-ID: <4B2219AC.60105@zafena.se> Clemens Eisserer wrote: > Hi Xerxes, > > Thanks a lot for testing :) > > >> I hit some issues when running openjdk with the jules renderer on my ARM >> PC-Z1, see the attached images, basically all menus are empty of typefaces >> and no vector graphics are dawn at all. the only things that seems to be >> drawn ok where gray panels and some images. Images gets funny though when >> the frame are redrawn after being overlapped by a window, see the green >> glitches in the jules-xrender-arm-redraw-glitch.png . >> > > Outch, that looks really bad. Even stuff where jules isn't involved > seems to fail. > I guess there are some problems in the new xrender pipeline :-/ > To be honest I don't have a clue what is going wrong here, > maybe some structure-alignment assumptions are not valid on arm. > However except for font-rendering most things aren't that ugly, I > can't imagine what would cause problem. > On the other hand, I've just bought a 4GB SD card for my N800 and I've > plenty of spare time during holidays now :) > > Just to be curious, does > -Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine > -Dsun.java2d.xrender=false work for more complex things like > Java2Demo? > > - Clemens > Running with -Dsun.java2d.renderer=sun.java2d.jules.JulesRenderingEngine -Dsun.java2d.xrender=false produces no gui errors, im a bit puzzled though since i dont see "Jules library successfully loaded" so im not sure if Jules are running at all when -Dsun.java2d.xrender=false. I tested to run some tests using the old xrender backends found in icedtea6 and i can verify that I got the same problematic results, I found out that the actual problem seems to be that my screen are using the xorg FBDEV and that makes XRender unhappy. I verified this xorg driver theory by running Jules and xrender=True across a remote ssh -X conenction to see if everything then looks ok. and yes it does! So the way for me to fix my issues would be to get hands on some better xorg drivers than FBDEV. Or fixup FBDEV to support the XRender API. Cheers Xerxes From linuxhippy at gmail.com Sun Dec 13 15:01:19 2009 From: linuxhippy at gmail.com (Clemens Eisserer) Date: Sun, 13 Dec 2009 18:01:19 -0500 Subject: Port of jules 0.0.1 to Icedtea7, and first impression when running on ARM. In-Reply-To: <4B2219AC.60105@zafena.se> References: <4B210E64.80007@zafena.se> <194f62550912101111o231ecb3td357469e871dc89a@mail.gmail.com> <4B2219AC.60105@zafena.se> Message-ID: <194f62550912131501h4f621404q1220d1dafc737933@mail.gmail.com> > So the way for me to fix my issues would be to get hands on some better > xorg drivers than FBDEV. > Or fixup FBDEV to support the XRender API. The strange thing is, as far as I know fbdev is pixman only - therefor falls back to software-rendering for almost everything. And gtk application seem to work just fine, although gtk also uses xrender through cairo. Maybe I am doing something stupid ... Thanks again, Clemens