Hi,
I should add that so far I wasn’t able to repeat this glitch and no other
application was affected, so this may also be completely unrelated.
-hendrik
> On Dec 29, 2020, at 21:07, Hendrik Schreiber wrote:
>
> Hi,
>
> For what it’s worth: I have tried this build with met
Jim,
if there isn’t a dedicated bug report for this (meaning: lack of optimization
for macOS), please do create one so that it at least is documented somewhere.
Thank you,
-hendrik
> On Jun 5, 2020, at 13:59, Jim Laskey wrote:
>
> I know there was a discussion about this elsewhere but I woul
Hey there,
just curious regarding the state of this bug.
@Karl: Did someone review your patch? Or did you gain any additional support
for submitting it?
It would be a shame to not incorporate the fix, just because it was simply
forgotten…
-hendrik
> On Jan 12, 2017, at 08:58, Hend
> On Jan 12, 2017, at 04:22, Karl von Randow wrote:
>
> I’m sorry I didn’t discover this bug somehow!
Who cares?—I really appreciate that you provide a fix after no progress has
been made for more than half a year!
That’s awesome.
-hendrik
ormalize the size of UI elements on various
> displays of different display resolution, but EXIF resolution tag processing
> would be more of a pre-press feature of an image display and layout editor.
> That goes a bit beyond the current effort...
>
> ...jim
&g
> The reason for this is both to have an explicit token for the regular scale
> factor and also so that this matches with the default image suffix of "@2x"
> so that we can add more ways to provide alternate media such as "@120dpi"
> which are consistent with the values we use here.
>
> BTW, w
> On Aug 25, 2015, at 23:26, Jim Graham wrote:
>
> Should we list the naming conventions that we support (mainly just "@2x"?),
> or should that be listed in the documentation of the various getImage() and
> createImage() methods?
As mentioned back in April
(http://mail.openjdk.java.net/piper
> On Apr 1, 2015, at 15:46, Alexander Scherbatiy
> wrote:
>
> On 3/27/2015 12:48 AM, Jim Graham wrote:
>> Hi Alexander,
>
> http://cr.openjdk.java.net/~alexsch/8029339/webrev.07/
> I have updated the fix according to the comments except RenderingHints.
Alexandr,
I've noticed that the Mul
> On Apr 3, 2015, at 15:18, Sergey Bylokhov wrote:
>
> 02.04.15 12:19, Hendrik Schreiber wrote:
>> Sergey, do I understand this correctly, when I say, it seems that using the
>> "wrong" image type there is a two time penalty, but once the image is cached
>
> On Apr 1, 2015, at 16:32, Sergey Bylokhov wrote:
>
> Hi, Jim.
> 31.03.15 0:00, Jim Graham wrote:
>> Hi Sergey,
>>
>> Slow us down where?
> Slowdown occurs before the images will be cached in the native texture. At
> least two times: for the first time "image->conversion->window" blit and for
> On Mar 26, 2015, at 22:52, Jim Graham wrote:
> On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
>> Nevertheless, I wouldn't mind some feedback regarding converting
>> ToolKitImages easily to something that can be drawn faster
>> (TYPE_INT_ARGB_PRE). Don't we al
> On Mar 26, 2015, at 16:32, Alexander Scherbatiy
> wrote:
>
> On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
[...]
>>
>> Therefore, in the spirit of
>> https://bugs.openjdk.java.net/browse/JDK-8059943, I'd like to suggest, to
>> either move sun.aw
> On Mar 13, 2015, at 14:34, Alexander Scherbatiy
> wrote:
>
> Could you review the proposed API based on MultiresolutionImage interface:
>http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
Not that it counts much, but to me the proposed API looks good in that it
provides us with mul
Hey there,
I'm in the process of moving some custom code to take advantage of the fairly
new MultiResolutionImage capabilities.
Loading multi resolution stuff works nicely, but I fear drawing is a bit of a
problem.
In my old mechanism, I would
- load images using the toolkit
- create a screen-
On Oct 29, 2014, at 16:22, Sergey Bylokhov wrote:
> Hi, Hendrik.
> You can find some process information here:
> http://openjdk.java.net/projects/jdk8u/
> http://openjdk.java.net/projects/jdk8u/approval-template.html
>
> I will send an approval request for jdk8u for you, after I'll push this
>
On Oct 27, 2014, at 17:44, Sergey Bylokhov wrote:
> The fix looks good.
> webrev: http://cr.openjdk.java.net/~serb/Hendrik/8057830/webrev
>
> However, before we can accept fixes from you, you will need to have an OCA
> signed. Please find more details here:
> http://www.oracle.com/technetwork/c
On Sep 25, 2014, at 15:16, Hendrik Schreiber wrote:
> On Sep 25, 2014, at 14:07, Andrew Brygin wrote:
>
>> the bug report mentions that the problem is reproducible on 1.8.0-b132.
>> Is the problem reproducible with 8u20?
>
> The customer runs 8u20.
> I have asked h
ct 1, 2014, at 17:03, Hendrik Schreiber wrote:
> Thanks for the endorsement, Denis.
> Much appreciated!
>
> -hendrik
>
> On Oct 1, 2014, at 13:19, Denis Fokin wrote:
>
>> Hi Hendrick,
>>
>> I am not a reviewer, but the fix looks good to me.
>>
Thanks for the endorsement, Denis.
Much appreciated!
-hendrik
On Oct 1, 2014, at 13:19, Denis Fokin wrote:
> Hi Hendrick,
>
> I am not a reviewer, but the fix looks good to me.
>
> Thank you,
> Denis.
>
> On 22 Sep 2014, at 12:19, Hendrik Schreiber wrote:
>
On Sep 25, 2014, at 14:07, Andrew Brygin wrote:
> the bug report mentions that the problem is reproducible on 1.8.0-b132.
> Is the problem reproducible with 8u20?
The customer runs 8u20.
I have asked him to collect the j2d trace output and run the testcase code.
> Also, according to comments in
Hey,
I have a customer experiencing https://bugs.openjdk.java.net/browse/JDK-8038998
(buttons/checkboxes/menus etc have disapearing text or fail to repaint
properly), which unfortunately was closed.
Ketan Shah documented that more information was requested, but fails to state
what information
Hi,
Bug: https://bugs.openjdk.java.net/browse/JDK-8057830
On OS X, CGLGraphicsConfigInfo is destroyed by OGLGC_DestroyOGLGraphicsConfig,
however the pointer to it still hangs around for a while and is not reset to
NULL, until we get rid of it with a Disposer later on.
In the meantime it appear
On Nov 7, 2013, at 10:05 PM, Jim Graham wrote:
> Thanks Hendrik, no apologies necessary.
>
> I haven't been involved much in the MacOS port so my question was actually a
> legitimate call for information and not meant to criticize anyone's input. I
> actually searched for a developer page tha
On Nov 7, 2013, at 1:03 PM, Clemens Eisserer wrote:
>> PLEASE, PLEASE don't make us wait until JDK9 for something that worked
>> really well in Apple's JDK6.
>
> An internal API doesn't mean you can't use it with JDK8, only that it
> is not part of the default API (which is more or less the same
>
>>
>> The @2x mechanism should be based on different API. I guess it would have
>> to be internal-only for 8.0 and could be exposed to allow developers to call
>> it and possibly to be a provider for it in JDK9...
PLEASE, PLEASE don't make us wait until JDK9 for something that worked reall
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 develope
26 matches
Mail list logo
