[JAVA2D] java2d Compositing - OpenGL fragment shaders

- Original Message - From: Michele Puccini [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 21, 2007 7:41 PM Subject: java2d Compositing - OpenGL fragment shaders A little followup.. the fragment shader code of my previous email was bloody wrong as the docs say:

[JAVA2D] java2d Compositing - OpenGL fragment shaders

Hello all at java2d, Hello Chris, after bouncing my head for some time over OpenGL, alpha compositing, accumulated and premultiplied alpha I decided (curiosity) to take a look at the j2se6 source code just to see what happens behind the scenes. All I discovered (surprise ?) is that the OpenGL

Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders

Michele, I guess the reason why you implement it using a fragment shader is to see a speed increase. What speed increase can we expect using your technique (What CPU/Graphic card are you using) ? I was thinking of implementing something similar for BufferedImageOp ( speed up ConvolveOp for

Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders

Hi Mike, of course the main aim is always speed, speed, speed. Your question about speed gains is quite crucial and the answer may be of course very complicated to elaborate. Just mix up some aspects: implementation - how can shaders be implemented in java2d-ogl ? - what can be affected

Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders

Michele, My question was more: What speed improvement did you personally measure using the shader implementation vs the plain java one (x2 faster ?, x10 ? , ect...) I'm also interested in the hardware config (CPU/GPU) you've used to take those measures, because of course, the result will be

Re: [JAVA2D] JDK6 and com.sun.image.codec.jpeg.JPEGCodec compile failure

Hi Philip, While I understand one should not use this class, a lot of projects still do. You really shouldn't! ;-) Under JDK6, the following is actually resulting in a compile failure. com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and may be removed in a future release Can

Re: [JAVA2D] JDK6 and com.sun.image.codec.jpeg.JPEGCodec compile failure

Philip, Absolutely, You really shouldn't use com.sun.image.codec.jpeg.JPEGCodec. Code that uses this can't expect to run on all compatible Java implementations. Image I/O has been around since 1.4 and is the standard supported solution. FYI this is quite timely as we are soon to propose at the

[JAVA2D] Drawing transparent image is incredibly slow - please help!

I've written an application that loads an image and draws a repeated grid of this image to the screen like a chessboard. When I use a jpeg or a png (with no transparency) I can draw 1000 of these instantaneously (or at least fast enough for my purposes). When I use a transparent image (for

Re: [JAVA2D] JDK6 and com.sun.image.codec.jpeg.JPEGCodec compile failure

Thanks to everybody for the help! I will contact the folks at jcaptcha (a very popular captcha implementation) and see about helping them migrate their code from the com.sun.* packages. I think if we hit a few of the projects out there in javaland, folks will then have the examples they need

Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders

Hi Mik, On Feb 22, 2007, at 2:11 AM, Michele Puccini wrote: A little followup.. the fragment shader code of my previous email was bloody wrong as the docs say: Notice that the fragment shader has no access to the frame buffer. This implies that operations such as blending occur only after the

Re: [JAVA2D] Drawing transparent image is incredibly slow - please help!

Hello, yes, 17 seconds seems to be very excessive. Here is a couple of suggestions: 1. instead of using raster when when creating a copy of your image, just do a drawImage into a new BufferedImage: shapeImageCopy = graphicsConfig.createCompatibleImage(

Re: [JAVA2D] java2d Compositing - OpenGL fragment shaders

BTW, if you're following this thread on the forum (and not the mailing list), I posted a long reply on a separate thread: http://forums.java.net/jive/thread.jspa?threadID=23376tstart=0 Thanks, Chris [Message sent by forum member 'campbell' (campbell)]

Re: [JAVA2D] Drawing transparent image is incredibly slow - please help!

I am running Windows XP. The image I was testing with is 185 x 185 pixels (so not big). Interesting. I had similar experience about month ago, but on linux. Since it was the 64 version I thought it is related to rather imature graphics drivers and their rendering support on that platform.

[JAVA2D] draw on TiledImage as one unified image, still managing memory using tiles

Suppose that it's a huge diagram with thousands of nodes and links and I have an algorithm to arrange them in a nice manner. before splitting this huge image into lots of smaller and more manageable pieces (and I have to do this to present them in the browser), I have to draw the whole picture

Re: [JAVA2D] best approach for huge image

I am moving this thread to http://forums.java.net/jive/thread.jspa?threadID=23403 thanks [Message sent by forum member 'shikida' (shikida)] http://forums.java.net/jive/thread.jspa?messageID=204881 === To unsubscribe, send

Re: [JAVA2D] draw on TiledImage as one unified image, still managing memory using ti

Suppose that it's a huge diagram with thousands of nodes and links and I have an algorithm to arrange them in a nice manner. before splitting this huge image into lots of smaller and more manageable pieces (and I have to do this to present them in the browser), I have to draw the whole

Re: [JAVA2D] draw on TiledImage as one unified image, still managing memory using ti

well, it seems this is not a new problem... http://forum.java.sun.com/thread.jspa?threadID=437539messageID=1969914 is there anything ready I can just get/buy and use? or any snippet? thanks in advance [Message sent by forum member 'shikida' (shikida)]

Re: [JAVA2D] draw on TiledImage as one unified image, still managing memory using ti

Let me outline what you'd have to do: 1. Create a memory mapped file. What you get is a ByteBuffer instance. 2. Create a DataBuffer subclass, which's getElem() and setElem() methods delegate to the ByteBuffer's get() and put() methods. 3. Create a BufferedImage that wraps the above DataBuffer

[JAVA2D] Retiring the package com.sun.image.codec.jpeg

The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. It has never been part of the platform specification and is not part of any compatibility test suite and so compatible Java implementations

Re: [JAVA2D] Drawing transparent image is incredibly slow... PROBLEM JRE NEW VERSION

Dmitri - Thanks for all the suggestions (Jan - you might be interested in what I found): 1) Tried this and made no difference 2) This was what I was doing! Sorry that was my bad post. I am copying everything to a BufferedImage and then writing this to the screen. 3) I tried using non-default

Re: [JAVA2D] draw on TiledImage as one unified image, still managing memory using ti

Hi, I am chiming in a little late because I was swamped with other things. I am involved in a couple of Open Source GIS projects where we handle single image which can be couple of gigabytes but also we work with large mosaics and pyramids. I am not sure I understood 100% your problem, but what

Re: [JAVA2D] draw on TiledImage as one unified image, still managing memory

I´ve followed Roman´s directions (thanks Roman!) and I´ve coded something that (seems to) partially solves my problem. I am not sure if it´s correct (it seems to be, based on a few png´s I´ve generated), but I still have to test the performance using my application, that generates much more

Re: [JAVA2D] Using custom DataBuffer

take a look at this thread http://forums.java.net/jive/thread.jspa?threadID=23403tstart=0 best regards [Message sent by forum member 'shikida' (shikida)] http://forums.java.net/jive/thread.jspa?messageID=204913 === To

[JAVA2D] Sub pixel sampling of Raster or DataBuffer in BufferedImage.

Hi, I'm writing an applet to show slightly distorted images. The applet it to apply small corrective mapping to straighten out the image for better viewing. The problem is that the corrections on a small image can be less than a pixel. It would be real handy if I could do sub-pixel averaging