Hi Jim,
I perfectly agree with your analysis.
My point was not to have it in the same class as the Porter Duff rules
implementation.
The only thing I am looking after is having these advanced blending modes
working with hardware acceleration pipelines.
Given the latest evaluation of RFE
jav...@javadesktop.org wrote:
Hi Jim,
I perfectly agree with your analysis.
My point was not to have it in the same class as the Porter Duff rules
implementation.
The only thing I am looking after is having these advanced blending modes
working with hardware acceleration pipelines.
Given the
Can ADD and MULTIPLY be expressed using Porter/Duff equations as per the
existing rules? I seem to recall that they require clipping the result
which none of the other modes require. The P/D chapter in Foley and
vanDam mentiones PLUS, but it doesn't describe it in the same terms as
the
Hi everyone,
quick question more or less related to this topic on hardware accelerated
drawing:
I was desperately waiting for what was supposed to be called the PhotoComposite
API that would allow new blending modes (ADD, MULTIPLY, OVERLAY, ...) to be
used as Composite for the Graphics2D API.
Chris Campbell wrote:
On Feb 6, 2009, at 5:46 AM, jav...@javadesktop.org wrote:
Hi,
I'm trying to get straight in my head exactly which graphics rendering
surfaces can get hardware accelerated in Java. There seems to be a lot
of confusing/half specified information around.
Firstly let me
Hi,
I'm trying to get straight in my head exactly which graphics rendering surfaces
can get hardware accelerated in Java. There seems to be a lot of confusing/half
specified information around.
Firstly let me state I'm using Java 6u12 on a Windows XP machine. I'm
interested in rendering TO
On Feb 6, 2009, at 5:46 AM, jav...@javadesktop.org wrote:
Hi,
I'm trying to get straight in my head exactly which graphics
rendering surfaces can get hardware accelerated in Java. There seems
to be a lot of confusing/half specified information around.
Firstly let me state I'm using Java
Chris Campbell wrote:
No, the DirectDraw pipeline no longer exists as of JDK 6u10. If the
D3D pipeline is disabled (or can't be enabled due to driver/hardware
problems) we switch back to using GDI for onscreen rendering, and
VolatileImages/BufferStrategy then become backed by system memory
2) 6u10 added native font rendering to Java. When is this enabled?
Is it always used in all pipelines or just in the D3D rendering?
Its implemented in a manner independent of pipelines. It wouldn't have
been worthwhile
to do it in a way that only worked on some surfaces, or that was
The sole exception to this is the glyphs from fonts
that are in the
jre/lib/fonts directory - ie the fonts
that ship with Java. For the Windows JRE this means
Lucida Sans Regular.
There is another, much bigger exception - painting texts on translucent
surfaces (when the current SrcOver
The question is where the native rasterisation is used vs where
the Java rasteriser is used. We don't use LCD rasterisation of
either flavour in such cases.
There are also limitations to where Microsoft can or do apply cleartype.
I've seen it in the distant past although I can't say for certain
Wow, I didn't expect such quick replies! Thanks everyone, your answers are
clear and very useful. Thanks for clearing that up.
[Message sent by forum member 'fred34' (fred34)]
http://forums.java.net/jive/thread.jspa?messageID=330628
12 matches
Mail list logo
