This bug has probably already been committed, but I am wondering if
there was a reason why the generics identifiers were left as "Object"
rather than using the known key and value types?
For example, RenderingHints.Key.identityMap should really be
HashMap>
RenderingHints.hintmap should als
Make that > for the first map...
...jim
On 3/22/2013 6:34 PM, Jim Graham wrote:
This bug has probably already been committed, but I am wondering if
there was a reason why the generics identifiers were left as "Object"
rather than using the known key an
I don't think the constant would add any value and would just cause someone looking over
the code to wonder what kind of magical value means NO_SCALE when the value is so
obvious. I think anyone can realize that 1 or 1.0 means "not scaling" with
about 2 neurons firing. The mystery created by
J2DBench does not have a regression test mode unfortunately.
Clipping in the stroker and dasher is doable, but it is complicated by the fact that stroking adds
decorations that are not always easy to account for. Round joins and end caps are easy - they
"grow" the path by exactly half the line
Other thoughts - using chained buckets of edges instead of one single long list. It
would be easier to keep a pool of buckets (each holding, say, 256 edges?) than a
"one-size-fits-all" pool of arrays. Then all you have to do is keep high water
marks on the number of simultaneously used bucket
On 3/30/2013 5:25 AM, Laurent Bourgès wrote:
I would like first try / do simple things: skip segments totally out of the
clipping + margin (10%) to avoid the dasher create millions of invisible
segments.
it seams simple but check each segment could become a performance bottleneck
too !
Two
Hi Sergey,
Did you check for possible performance hits for the new transform save/compare
code in BufferedContext? That is significantly more work per validate().
Also, isn't this case only used in the case where the caller specified a null
xform in the argument list? Does that happen (or,
I just wanted to add:
On 4/8/2013 2:19 PM, Jim Graham wrote:
It's already done and the code is written, but in retrospect, I'm not sure how
much the optimizations in getTransform/setTransform are worth compared to the
easy readability of having the transforms done linearly in a L
Hi Laurent,
Quick questions - which benchmarks were run before/after? I see a lot of
benchmark running in your Pisces improvement thread, but but none here.
Also, this should be tested on multiple platforms, preferably Linux, Windows
and Mac to see how it is affected by differences in the pla
Hi Laurent,
I haven't looked at the changes in depth yet, but I wanted to echo my comments
on the AAShapePipe thread - make sure you do benchmark testing on multiple
platforms and double check if caching small objets actually helps anything
(otherwise it is unnecessary code complexity and poss
Hi Laurent,
The allocations will always show up on a heap profiler, I don't know of any way
of having them not show up if they are stack allocated, but I don't think that
stack allocation is the issue here - small allocations come out of a fast
generation that costs almost nothing to allocate
I took one last glance through the .06 webrev. I don't see any more
issues...
...jim
On 10/4/13 12:21 PM, Sergey Bylokhov wrote:
Hi, Jim, Phil.
Once again=) I assume, that you haven't additional comments? Can I
consider you as the reviewers?
Note that I plan push it to awt-dev
I'm pretty familiar with all of this code and there aren't any places
that save the tile array that I remember. The embedded code that Pisces
was taken from had some caching of alpha arrays, but we didn't use or
keep that when we converted it for use in the JDK...
It occurs to me that since y
PI change).
What do you think ?
Laurent
2013/4/11 Jim Graham
I'm pretty familiar with all of this code and there aren't any places that
save the tile array that I remember. The embedded code that Pisces was
taken from had some caching of alpha arrays, but we didn't use or keep t
If I'm reading this correctly, your patch is faster even for a single
thread? That's great news.
One of the problems we've had with replacing Ductus is that it has been
faster in a single thread situation than the open source versions we've
created. One of its drawbacks is that it had been d
One thing about modifying the iterators. I originally commented that I
thought an object there was a bit much but it helped Denis, who was
doing all the work after all, keep the code organized in his mind. I'm
not sure what kind of measurements he made, but he didn't feel that they
were hurti
e code much less
problematic to just weed the empty answers out early.
As far as "are any Developers expecting a usefully non-degenerate empty
answer" then I don't think so...
...jim
On 4/18/13 6:24 AM, Sergey Bylokhov wrote:
Hello Jim.
On 1/17/13
Hi Patrick,
Since the fix involves printing it may be better to work through Phil
Race since that is more his area. He can hook you up with the necessary
"paperwork" and review/integrate your fixes...
...jim
On 4/18/13 11:18 AM, Patrick Reinhart wrote:
Hi James,
I'
in the given patch. This small
change can be applied easily...
Le 22 avr. 2013 23:05, "Jim Graham" mailto:james.gra...@oracle.com>> a écrit :
One thing about modifying the iterators. I originally commented that I thought
an object there was a bit much but it helped Denis, who w
Hi Laurent,
On 4/24/13 1:59 AM, Laurent Bourgès wrote:
Originally the version that was used in embedded used RLE because it
stored the results in the shape itself. On desktop I never found
that to be a necessary optimization especially because it actually
wastes memory for no ga
On 4/24/13 1:59 AM, Laurent Bourgès wrote:
Jim,
First, here are both updated webrev and benchmark results:
- results: http://jmmc.fr/~bourgesl/share/java2d-pisces/patch_opt_night.log
- webrev: http://jmmc.fr/~bourgesl/share/java2d-pisces/webrev-2/
Some comments on the webrev:
- This caching o
uot;lastrow.999". So, the first
coordinate not included would be "lastrow+1" which is simply adding +1
to the sub-pixel "max" value that was given.
I fixed these limits to have correct rendering due to dirty rowAARLE reuse.
If there was a bug before I'd
Hi Laurent,
On 5/2/13 1:48 AM, Laurent Bourgès wrote:
xc = computed crossing value for the current scan line;
ceil(xc - 0.5);
Agreed; however, pisces code never performs such rounding: for me,
ceil(x - 0.5) means (int) Math.round(x).
(int) Math.round(x) is almost the same function, b
This is amazing work, Laurent! I'll look over the code changes soon.
Note that the "2 edge arrays" issue goes away if we can use native
methods and C structs. It may be faster still in that case...
...jim
On 5/6/13 6:43 AM, Laurent Bourgès wrote:
Jim, Andrea & java2d
Hi Laurent,
On 5/9/13 11:50 PM, Laurent Bourgès wrote:
Jim,
I think that the ScanLineIterator class is no more useful and could be
merged into Renderer directly: I try to optimize these 2 code paths
(crossing / crossing -> alpha) but it seems quite difficult as I must
understand hotspot optimiz
I never saw the original fix on this, but I don't think it is supported
to modify clipRegion directly like that since it is a field that is kept
in synch with other fields. This fix has an extremely high potential to
cause maintenance problems in the future if the bookkeeping on these
related
Hi Laurent,
On 6/11/13 5:21 AM, Laurent Bourgès wrote:
Dear Java2D members,
Sorry to ask but does anybody care about improving java2D rendering
(quality, performance) ?
I sent several emails for one month and nobody answered.
Should I consider that there is no interest and give up ?
I apolo
I'd have to look, but I think we could raise our precision in the X
direction without costing too much in performance since it just affects
the scale of our sub-pixel contributions per pixel. But, raising it in
the Y direction is where the performance starts to hurt us because it
means more di
hich will attempt to preserve the dimensions
of empty clips. So, the "preserve the size of an empty clip" support
is new.
Yes it is new in case of Rectangle2D, but now it works in the same
way as for Rectangle.
On 23.04.2013 1:11, Jim Graham wrote:
I think if empty (un)transforms
Hi Laurent,
On 5/29/13 2:01 AM, Laurent Bourgès wrote:
Two comments:
- hotspot takes some time to optimize the very large
Renderer.endRendering() and ScalineIterator.next() methods: probably
because these methods represents too many byte codes (many loops ...)
- I tried merging them but it seems
I believe there is a file called LoopMacros.h that defines the skeletons
for the functions. Then there are a number of files named after a
particular pixel format, like "IntArgb.c", which contain a bunch of
invocations of those macros. Each macro invocation expands into an
entire function.
One suggestion I'd add, though, is that the GET() macro is written so as
to be difficult to maintain. It both declares a variable and executes
code which means it does not act like a declaration, nor does it act
like a piece of code. Also, if someone needs to create a similar type
of macro la
d fix:
http://cr.openjdk.java.net/~bae/8020983/8/webrev.02/
Thanks,
Andrew
On 7/30/2013 4:18 AM, Jim Graham wrote:
One suggestion I'd add, though, is that the GET() macro is written so
as to be difficult to maintain. It both declares a variable and
executes code which means it does not
Apologies as this is an old bug, but I just looked at the fix and it
seems to me that it will allow shearing transforms to pass because the
tests are incomplete. The 0or180 flag only tests if the horizontal
lines stay horizontal, but they could shift relative to each other in
increasing Y whic
From looking at the code, it looks like this is probably a bug. The
default color model for TYPE_INT_RGB is non-premultiplied which means
that we should have unmultiplied the alpha before we stored the color.
Now, if you had used an alpha of 0, then we would have been unable to
reverse any pre
I'm not the greatest expert on generics (in particular, in terms of
issues of retrofitting generics into existing public code without
breaking compatibility), but I'll note that the properties on an image
were always "documented" to be String->Object, but that was well before
generics and so we
ether an OGL
opaque surface supplies a ColorModel that claims it is premultiplied or
not. If it states that it is pre, then its behavior is correct...
...jim
On 10/2/13 3:03 PM, Jim Graham wrote:
From looking at the code, it looks like this is probably a bug. The
de
Hi Clemens,
The definition of COMP_ISCOPY is that a value simply needs to be stored
in the destination without any blending to perform the rendering. CLEAR
essentially behaves like SRC, but with a hardcoded color of all 0s (i.e.
as long as you ignore the current color), and SRC_IN to an opaqu
If this is just the text pipeline, then I'm guessing that CLEAR and
SRC_IN are rarely used anyway...
...jim
On 10/5/13 8:38 AM, Clemens Eisserer wrote:
Hi Jim,
You should be able to use the same code as SRC for CLEAR, but you are
rejecting that operation. And, if the destina
There is a bug here because we should choose non-interfering sets of
pixels for abutting shapes, like we do for rendered shapes (and clipping
should use the same rules as non-AA rendered shapes). Adjacent shapes
that share a common border will divide the pixels along that border
between them s
nks
kalyan
On 10/2/13 3:13 PM, Jim Graham wrote:
I'm not the greatest expert on generics (in particular, in terms of
issues of retrofitting generics into existing public code without
breaking compatibility), but I'll note that the properties on an image
were always "documented&qu
Hi Clemens,
Now that we've narrowed it down to a quadrant rotation at best, can't we
get by with only transforming x,y and x+w,y+h? Or is the adjust method
used from other locations that might have a non-quadrant transform? (Or
do any callers depend on srcCoords and dstCoords being fully
po
brev.zip>.
The new version is uploaded here:
http://cr.openjdk.java.net/~art/srikalyc/8025684.02/
Thanks,
Artem
--
Thanks
kalyan
On 10/2/13 3:13 PM, Jim Graham wrote:
I'm not the greatest expert on generics (in particular, in terms of
issues of retrofitting generics into existing
Hi Clemens,
I sincerely apologize for not seeing this sooner, my email sorting is a
little primitive, but I should check these alternate folders more often.
The one thing I am concerned about here is the rounding that is going on
for scaled images. You removed a comment about non-integer coo
Ah, I see. And, I was about to rant about MT issues, but I see now that
this is all inside an AWTLock.
I guess that also explains why the source coordinates were multiplied by
the scale, though that seems a rather odd way to handle these issues.
A new question/issue - on line 314, what happe
Why is getScaledInstance() being consulted here? It seems a misuse of
that method.
The method was designed to return a rescaled version of the same pixels
that you would get if you examined the raw pixels. You are overriding
it to return a different image. That does not fit in with the orig
On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
On 11/6/2013 5:39 AM, Jim Graham wrote:
Why is getScaledInstance() being consulted here? It seems a misuse of
that method.
We need to introduce a new API that allows developers to return
scaled images for HiDPI displays.
Then we should
Hi Clemens,
On 11/6/13 9:38 AM, Clemens Eisserer wrote:
A new question/issue - on line 314, what happens if the case is both
quadrant rotated and extra-alpha'd? Either of those will get us into that
code block, but also both of them could be true at the same time in which
case it looks like you
On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
Hi , Jim.
On 07.11.2013 1:40, Jim Graham wrote:
On 11/6/13 5:19 AM, Alexander Scherbatiy wrote:
On 11/6/2013 5:39 AM, Jim Graham wrote:
Why is getScaledInstance() being consulted here? It seems a misuse of
that method.
We need to introduce a
Thanks Clemens, I completely forgot about how this all interacts with
old 1.1-style "generated images", but that is a further complication in
that those images that never sent an IMAGE_COMPLETE notification were
dynamic in a very unhealthy way and creating a scaled instance was just
one of thos
Hi Sergey,
On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
On 07.11.2013 4:09, Jim Graham wrote:
On 11/6/13 3:09 PM, Sergey Bylokhov wrote:
That method "returns a scaled version of *this* image". It
specifically refers to recombining the pixels of the image you would
normally get into a
On 11/6/13 5:20 PM, Sergey Bylokhov wrote:
In other words:
package sun.awt.image;
public interface MultiResImage {
public Image getResolutionVariant(float resolution);
}
public class MacImage extends Image implements MultiResImage {
public Image getResolutionVariant(float resolution)
On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
In this example there is a problem. For example we have 2
BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
- Image A draws to the image B
- Image B draws to the window.
When window is moving from the screen x1 to the screen x2 a
How did Apple expose this in their JDK6?
For the record, I'm saying that getImage("myimage.[fmt]") can load the
@2x image and drawImage() could use that when needed - all of that can
happen without any public API.
But, for a developer to query a Toolkit Image loaded via getImage("...")
to fi
On 11/7/13 6:18 AM, Sergey Bylokhov wrote:
On 07.11.2013 11:01, Jim Graham wrote:
On 11/6/13 6:15 PM, Sergey Bylokhov wrote:
In this example there is a problem. For example we have 2
BufferedImages/ToolkiImagest A and B; Both wants be scaled perfectly.
- Image A draws to the image B
On Nov 7, 2013, at 9:30 PM, Jim Graham wrote:
How did Apple expose this in their JDK6?
For the record, I'm saying that getImage("myimage.[fmt]") can load the @2x
image and drawImage() could use that when needed - all of that can happen without any
public API.
But, for a develo
On 10/31/13 9:19 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8011059/webrev.04/
I'd like to point out a potential issue here with respect to ImageObserver.
Typically, when the ImageObserver is notified that the image loading is
Hi Alexander,
Some minor issues with this fix:
- All RenderingHints have a default setting where the system can choose
for you. The primary thing that the default settings allow is for the
answer to be based off of another hint. Often the QUALITY hint provides
the swing vote if an individua
That last bullet item (or 2) is actually a bigger issue because I think
we've been ignoring it in coming up with the implementation, but it
could have a simple fix...
...jim
On 11/12/13 11:43 AM, Jim Graham wrote:
Hi Alexander,
Some minor issues with this fix:
Hi Andrea,
I think the problem is that there really aren't a lot of people working
directly on the JDK any more with direct experience with rasterizers.
For my day to day responsibilities, I have been officially working on
JavaFX for a couple of years, but I am also the engineer with the most
On 11/12/13 11:49 AM, Jim Graham wrote:
On 11/12/13 11:43 AM, Jim Graham wrote:
Hi Alexander,
Some minor issues with this fix:
- Descriptions for "on" and "off" should be something like "Use
resolution variants of images" and "Use only default resolutio
Hi Mike,
Just to confirm and be explicit, the Mac will choose the @2x version of an
image if that call returns 2.0 even if the user is rendering with a transform
that scales by .001?
...jim
On 11/12/2013 5:48 PM, Mike Swingler wrote:
On Nov 12, 2013, at 11:43 AM, Jim Graham
m causes the rect in the pixel backing store to be the same size or
smaller than the @1x.
I'll privately send along a little app that demonstrates this.
Regards,
Mike Swingler
Apple Inc.
On Nov 12, 2013, at 5:52 PM, Jim Graham wrote:
Hi Mike,
Just to confirm and be explicit, t
On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
On 12.11.2013 23:43, Jim Graham wrote:
- The logic in using the transform is also a bit murky. I think if
you set the scale on a retina display to exactly 1/2 it would use the
HiDPI version even though the scale was 1:1. Since I support not
e there is no any issue? If a MultiResolutionImage is not used
then all works as before. If a user implements MultiResolutionImage may
be he needs to have an information
about the actual drawn image in the observer even it is different
from the original.
Thanks,
Alexandr.
On 11/12/2013 11:43 PM, J
On 11/13/13 9:21 AM, Mike Swingler wrote:
- Hopefully the answers to the above 2 questions for Mike won't be surprising...
...jim
I hope I haven't surprised anyone. :-)
Regards,
Mike Swingler
Apple Inc.
Only that if the images are used on non-retina Macs then we mi
Hi Sergey,
On 11/13/13 11:25 AM, Sergey Bylokhov wrote:
On 13.11.2013 22:49, Jim Graham wrote:
On 11/13/13 4:33 AM, Sergey Bylokhov wrote:
On 12.11.2013 23:43, Jim Graham wrote:
- The logic in using the transform is also a bit murky. I think if
you set the scale on a retina display to
On 11/13/13 11:44 AM, Sergey Bylokhov wrote:
On 13.11.2013 23:25, Sergey Bylokhov wrote:
- The logic in using the transform is also a bit murky. I think if
you set the scale on a retina display to exactly 1/2 it would use the
HiDPI version even though the scale was 1:1. Since I support not
exa
22:49, Jim Graham wrote:
That's could be a problem. Is it possible to wrap imageObserver, which
was passed to the drawImage, and replace one image to another in the
WrapperImageObserver.imageUpdate()?
It's possible - the things to watch out for:
- they could hand the same IO in fo
Hi Alexander:
SunHints:
The text for the descriptions on the hints is still not updated to the text I
asked for in a previous message. Since there were multiple messages on that I
thought I would paste the particular comment I was referring to:
- Descriptions for "on" and "off" should be so
I did some more reading about the various ways in which the ImageObserver is
used and noticed the following points, some of which may be to our advantage.
Many of the drawImage() calls mention that they will notify the observer as the image is
"scaled or converted for the output device". I bel
heck instanceof...
...jim
On 11/19/2013 7:01 PM, Jim Graham wrote:
I did some more reading about the various ways in which the ImageObserver is
used and noticed the following points, some of which may be to our advantage.
Many of the drawImage() calls mention that they
...
...jim
On 11/19/2013 7:58 PM, Jim Graham wrote:
Based on the information below, I have the following suggestions...
We should probably allow asynchronous loading of the scaled resolution
variants. This is a minor variation of what the ImageObserver was originally
designed for, but technically
Hi Alexander,
I just noticed that the new interface was created in com.sun. I also note that
you discuss a number of issues below that relate to a developer creating one of
their own Multi-Resolution images. We should not be exporting an interface at
this point for a developer to do any of t
Hi Alexander,
On 11/22/2013 2:53 AM, Alexander Scherbatiy wrote:
On 11/21/2013 8:13 PM, Jim Graham wrote:
Hi Alexander,
I just noticed that the new interface was created in com.sun. I also note that
you discuss a number of issues below that relate to a developer creating one of
their own
Hi Alexander,
On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
Could you review the updated fix:
http://cr.openjdk.java.net/~alexsch/8011059/webrev.10/
- FLIP and TRANSLATE bit masks are also included for the SCALE
transform checking
Looks good.
- LWCToolkit checks an image in c
On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
On 11/23/2013 5:11 AM, Jim Graham wrote:
Hi Alexander,
If we are going to be advertising it as something that developers use
in production code then we would need to file this via CCC. With the
current implementation, any user that has their
with errors.
- sun.com package should be used?
- If MediaTracker was requested to load MultiResolutionImage,it should
load all versions?
On 26.11.2013 2:31, Jim Graham wrote:
On 11/25/13 5:51 AM, Alexander Scherbatiy wrote:
On 11/23/2013 5:11 AM, Jim Graham wrote:
Hi Alexander,
If we
ignored.
- Test is updated
Icons and CustomCursor issues are handled by 8028212 and 8024926 bugs
and depend on the current bug implementation.
Thanks,
Alexandr.
On 11/28/2013 3:21 AM, Jim Graham wrote:
The things I was talking about in the quoted email were mostly future
direction
a.net/~alexsch/8011059/webrev.12/
- Image observers are not cached now for the resolution variants
- base image width and height are checked in the wrapped image
observer
On 11/30/2013 3:27 AM, Jim Graham wrote:
Hi Alexander,
I suppose the wrapping solution works for ImageObservers, but I
2/3/2013 1:16 AM, Jim Graham wrote:
On 12/2/13 4:55 AM, Alexander Scherbatiy wrote:
On 11/30/2013 3:27 AM, Jim Graham wrote:
Hi Alexander,
I suppose the wrapping solution works for ImageObservers, but I think
the suggestion I gave in recent emails was to simply modify the
newInfo method (and a
Hi Mike,
One more question about @2x handling on MacOS.
Clearly, in the simple case of someone loading an ordinary "foo.png" and
painting it on a retina display without doing anything special with the
transform, it will be scaled up by 2x to retain proper size.
Also, clearly, if a "f...@2x.p
}
3118 }
(And perhaps this explains why I was pushing for the rv dimensions to be
determined on the fly - or hardcoded at 2x for now - in the wrapped
observer?)
...jim
On 12/3/13 9:49 AM, Jim Graham wrote:
Hi Alexander,
There is one last thing that I think
ould be enough...
...jim
On 12/3/13 9:49 AM, Jim Graham wrote:
Hi Alexander,
There is one last thing that I think I forgot to mention in SG2D that
might make some other comments I made make more sense. There is no
observer registered on the resolution variant in SG2D
12/3/13 10:26 AM, Jim Graham wrote:
Ah, sorry, one last (non-blocking) issue with the new code. Typically
we report image loading a scan line at a time for GIFs and
non-progressive JPEGs. The simple "divide by integer 2" lines in the
new observer will round OK for the x,y, but th
Perhaps the difference is that Dmitri is running on a display with Xbgr
which has to decompose the argb value and recompose it into a BGR value
- in the process it only moves the r, g, and b bits around.
Clemens is running on an Xrgb screen and so the pixelconverter just
passes on the argb val
Clemens Eisserer wrote:
however on the other side it maybe uses more memory (haven't looked at
the struct) so its a space/readability tradeof.
Well but most time people prefer their code over others so I thought
I am not in a good position to discuss this ;)
I think there are other areas where
One thing the bug report doesn't seem to mention is that the tiles are
32x32 (it implies it by talking about the 1024 values being copied), and
that there is a function which quickly tells you whether a tile is all
0s or all 1s so the renderer can either skip or do quicker fills of
regions that
Hi Ben,
Since it was only used for doing component layouts (in integer space),
it wasn't really needed anywhere, though I suppose that this begs the
question as to why Dimension2D was created in the first place.
(scratches head, doesn't remember).
Do you have a use case for it now?
majority of the votes cast.
The votes will be tallied and reported to this list
and to [EMAIL PROTECTED]
Only Members of the 2D Group are eligible to vote on this decision.
The current Members are:
Andrew Brygin
Brian Burkhalter
Christopher Campbell
Jerry Evans
Jennifer Godinez
Jim Graham
Steven
Hi Keith,
I'm curious if you need this behavior or not. We are planning to delete
the doc comment in JDK7 because the context objects are so cheap to
create that it wasn't really necessary. The comment was added early in
the development of the 2D API and was documenting what was in the code
Hi Clemens,
Clemens Eisserer wrote:
Hello,
I've (again) some questions about the X11 pipeline, just a few words
would be really helpful:
1.) When looking at X11SurfaceData.c, there are several notes that
this provides support for the software-loops to work directly on the
native data, e.g.:
And note that we aren't necessarily dealing with transforms in the
fastest way in all cases. Until recently we were focused mainly on
Swing performance and they mostly dealt with integer translations and
integer rendering requests. Nowadays as we focus the platform more on
rich clients and sc
I'd wager that trying to deduce the original transform from the
parameters at that point in the pipeline would be counter-productive
since the destination coordinates represent the product of the
coordinates that the user requested and the current transform, so you
may end up trying to set a tr
This is often a problem that can happen if you don't have a prototype
for the function. The default passing semantics for floating point is
to pass them as doubles unless there is a prototype that says that they
are floats.
Did you get the prototype correct, and did you make sure it was inclu
Good to hear it as it avoids some hard decisions.
Per-pixel consistency is always the desired goal, but sometimes you have
to look at what is possible to accomplish with the APIs we depend on and
make some hard decisions. If it would take a "work around" technique
that would take 100x as long
Vote: yes
Phil Race wrote:
I hereby nominate Doug Felt as a member of the OpenJDK 2D group.
Doug has made significant contributions to the Java 2D text APIs
and their implementation starting in 1997 and in every release from JDK 1.2
up to and including JDK 6. As part of the Taligent (later IBM
We don't use it for our software loops - we use TransformHelper instead.
I think the only 2 pipelines that use this type of loop are the OGL
and D3D pipelines and they probably only create subclasses that override
the method and vector it into the RenderQueue so this native method may
not have
Clemens Eisserer wrote:
"Extra alpha" has the same behavior for all AlphaComposite instances. In a
nutshell, the extra alpha value gets logically multiplied with the source
before the actual compositing operation. The AlphaComposite docs explain
this process in great detail (look for the A[sub]
Hi Mike,
Are you referring to the sun.dc.pr.PathStroker class?
That code is all licensed from a 3rd party and not open-source
compatible. It's functionality was replaced in the open-source version
of the JDK by the sun.java2d.pisces classes. Those are the open-source
implementation of Basic
201 - 300 of 822 matches
Mail list logo
