Bug 269 : partially transparent pixels are not drawn in parts of screen
Last modified: 2006-02-19 15:28

DUPLICATE of bug 121


Assigned To:

Attachment Type Created Size Actions
screenshot of bug image/jpeg 2006-02-09 11:10 82.28 KB

Description:   Opened: 2006-01-11 10:41
i boiled the bug down to the following code:
void setup()
size(500, 500);
colorMode(RGB, 100);

void draw()
if (mousePressed==true){
else { }

the bug is that the pixels appear only in some regions of the screen.

....you have to wait a bit....but everything else
would have meant more code (like in my original
code where it produced a weired image....)

this bug vanishes when the transparency in the stroke command is
set to no transparency (here 100). the bug is independent
of the window size (one gets the SAME regions) and independent
of the framerate as it seems, adding 10.3 is also not important
i chose it for visibility reasons (and the .3 for checking wether
the bug has something to do with doubles in the 2D renderer)
the bug seems also to vanish if one has not only single pixels (so thats a
the bug appeared in version 095 and 098. i tried it on
two different sonylaptops:
sony vaio pentium 4 running debian testing
sony vaio pentium 3 running debian testing

cheers nadja
Additional Comment #1 From fry 2006-01-11 12:56
can you post a screenshot (as an attachment) that depicts the problem?

what happens if you put point() in a loop and loop over the entire surface?
for (int i = 0; i < width; i++) {
for (int j = 0; j < height; j++) {
point(i, j);

sadly, i have a feeling that this is something with how java2d interacts with different graphics
cards. in some cases, point() doesn't show up at all..
Additional Comment #2 From nad 2006-02-09 11:10
screenshot of bug

sorry for making the attachment only now....
Additional Comment #3 From fry 2006-02-18 18:01
k, i think this is related to the issues with bug #121. thanks for the screenshot and shortened
code, much appreciated.

*** This bug has been marked as a duplicate of 121 ***
Additional Comment #4 From nad 2006-02-19 15:23
(In reply to comment #3)
> Additional Comment #3 From
> fry
> 2006-02-18 18:01
> <!--
> addReplyLink(3); //-->[reply]
> k, i think this is related to the issues with bug #121. thanks for
the screenshot and shortened
> code, much appreciated.
> *** This bug has been marked as a duplicate of 121 ***
so finally tim also had a look on this....
we tried the bug on three different graphics cards and
the bug was there on all of them.
we found:
the bug happened only if we didnt set smooth.
a possible explanation:
a line of length zero drawn with floats is apparently "rounded away"
and antialiased things become slightly thicker so the problem vanishes then.
the following code demonstrates this:
void setup()
size(200, 200);
colorMode(RGB, 255, 255, 255, 100);
//colorMode(HSB, 100);

void draw()
{ stroke(255,0,0,10);
for (int i=0;i<width/2;i++){
for (int j=0;j<height/2;j++) {
in our case for any NUMBERBETWEENZEROANDONE being a float
smaller then 0.8 the bug was there again for a bigger float
it vanished. so a possible solution would be not to draw
a line of length zero in the implementation of point().

greetings nad
Additional Comment #5 From fry 2006-02-19 15:28
right, it's a general issue with point(). sorry, i should have been more specific. there are
several things at work:

1) how java2d handles things that are small
2) the same issue with opengl or p3d
3) smoothing implementations are different across platforms (macosx, windows, linux)
4) implementation changes between releases of java (1.3 to 1.4 to 1.5 and 1.6 will change
5) stroke caps and joins can change the appearance as well
6) none of this is consistent across graphic cards, or even the same graphics card with
different settings.

basically, we have a general bug with point() that needs to be straightened out.