Thank you Jim,
Yes, I think you are right that the term rectangular in the documentation needs
clarification. Just because I wanted to know what rectangular means in this
context, I added the rotated tests.
And yes, the cause of one area being rectangular and the other not, while both
being eq
If VRAM is expensive to store per-pixel then the cost you pay to do the
blit(s) is dependent on the number of pixels.
If you are writing to the same VRAM pixels over and over because the
sysmem images overlap then you pay the cost to access pixels that will
later be overwritten.
By contrast
> The per-pixel overhead of accessing VRAM would
> probably be more
> noticeable than the per-operation overhead of getting
> the pixels into
> the pipeline - unless there was a lot of overlap
> between the sysmem images.
>
> With little or no overlap then it might even be
> faster to blit the
The per-pixel overhead of accessing VRAM would probably be more
noticeable than the per-operation overhead of getting the pixels into
the pipeline - unless there was a lot of overlap between the sysmem images.
With little or no overlap then it might even be faster to blit the
component sysmem
This is probably due to the fact that the Area class does not optimize
the case of 2 rectangular areas which abut each other top and bottom
into a single rectangular area, but it does optimize the horizontal case.
The isRectangular() method performs a trivial check for a single outline
with 4
Thanks for the info Michele. We haven't ran
any benchmarks on the new drivers.
Do you know if the issue affects opengl only or
is it generic?
Thanks,
Dmitri
Michele Puccini wrote:
Maybe it could be interesting for the java2d team too. Read it as a
kind-of warning.
Looks like the
A little followup:
after testing new and beta drivers with no luck, I decided to install a
different board: NV7600GT without changing the drivers.
The NV7600GT worked very well at x16 speed and the new drivers (169.21) were ok.
I removed the NV7600 and installed the NV8600GTX and this time was
Depends what you mean by "OpenType". If you mean specifically the CFF
(Postscript outlines) subset of OpenType then JDK doesn't support that.
There's an open RFE on this : http://bugs.sun.com/view_bug.do?bug_id=4356282
-phil.
[EMAIL PROTECTED] wrote:
Hello,
I noticed that [i]sun.font.FontManag
Are you tryingto convert the PNG image to greyscale? (TYPE_BYTE_GRAY would
assume that). If so, the Reason display differences among different
applications lies in the color conversion to greyscale.
There are various approaches to greyscale an image. The simplest would be: take
the average of
Hello,
I noticed that [i]sun.font.FontManager.getFontsFromPlatform()[/i] does not
return OpenType Fonts installed on a System (using Windows XP, SP2, Java
1.6.0_05-ea). Aswell creating new Font objects with OpenType Fonts as name does
not work too.
Is there any way to load and render Fonts w
Maybe it could be interesting for the java2d team too. Read it as a kind-of
warning.
Looks like the new 169.21 whql NVidia drivers and above (new betas) have
some problems in dealing with the PCIe bus, making it run at 1x instead of
16x.
This problem does not affect the previous 163.75 whql driv
11 matches
Mail list logo
