Bug 197 : Window fixed at 100 x 100 pixels
Last modified: 2007-10-16 06:32



Assigned To:

Attachment Type Created Size Actions

Description:   Opened: 2005-11-02 10:54
Have not been able to pinpoint the issue, but after running some apps where
size(100, 100) is used, the Display Window will not grown beyond this size
when, for example, size(400, 500) is run.
Additional Comment #1 From fry 2005-11-02 11:09

*** This bug has been marked as a duplicate of 195 ***
Additional Comment #2 From fry 2007-02-03 08:51
re-opening because finally found machines where this is reproducible. it's
a threading issue that tends to occur with very fast (or dual processor) or
very slow machines. the specific issue seems to be exclusive to windows,
though probably causes problems on osx too. also related to the window not
appearing on linux.

see bug #511 for the full run-down.
Additional Comment #3 From fry 2007-02-08 04:24
*** Bug 516 has been marked as a duplicate of this bug. ***
Additional Comment #4 From lannm 2007-07-18 07:52
Workarounds from discourse:

== greglitpc ==
I was having the exact same error with my applet, but I found that it
could be avoided by calling the size function multiple times, like so:

void setup(){

size(600, 300);
size(600, 300);
size(600, 300);


My applet now loads correctly every time. Hopefully, it will work with
yours, too.

== davbol ==
I only experience this with sketches using the JAVA2D renderer -- either
size(x,y) or size(x,y,JAVA2D). Yes, on windows, btw. If its a sketch that
will run either 2d or 3d, simply changing the renderer to P3D will stop
this behavior and the correct window size is produced without fail.
For those times where the P3D renderer CAN'T be used, I insert the
following as the first line of setup() and it seems to cure it (the exact
ms reqd isn't known, 50 is just what works for me):


try { Thread.sleep(50); } catch (InterruptedException e) { }
Additional Comment #5 From fry 2007-07-20 14:47
i assume this also means that the bug is still present in 0125? (i expect
it to be, but some related bugs were fixed so i didn't know if this one
wound up going away too)
Additional Comment #6 From lannm 2007-07-20 18:37
I can't confirm about 125. I'm TAing for a summer program where we ran into
this and I was just posting because the workarounds took me a while to
find. It's showing up semi-reproducibly in 124 on several oldish
(single-core) Alienwares. I'll try to reproduce in 125 on Monday.
Additional Comment #7 From Bas 2007-07-22 04:42
I can confirm that this bug still exists in 0125. Calling size() multiple times fixes it
for most - resource friendly - sketches. If you need more test systems to resolve
this I would be happy to help out. This bug is reproducible on both my Windows
machines. I have a Intel Core 2 Duo and AMD Athlon 64 X2 system where I can test
things on for you.
Additional Comment #8 From fry 2007-07-22 05:50
(In reply to comment #7)
> Additional Comment #7 From
> Bas
> 2007-07-22 04:42
> <!--
> addReplyLink(7); //-->[reply]
> This bug is reproducible on both my Windows
> machines. I have a Intel Core 2 Duo and AMD Athlon 64 X2 system where I
can test
> things on for you.

wow, both machines? i thought this was much more limited (i have access to
about half a dozen machines and haven't been able to get it to show up).
can you tell me anything more about your setup? like which version of
windows xp, which java, what graphics card, etc that you're using? anything
else that might be a clue?
Additional Comment #9 From Bas 2007-07-22 12:13
Here are my specs:

Processing 0123, 0124, 0125 Java included versions
Windows XP SP2 32bits
Java version "1.5.0_06"
AMD Athlon 64 X2 4200
NVIDIA 7600GT @ 1920x1200 32bbp

Processing 0124, 0125 expert versions
Windows Vista Business 32bits
Java version 1.6.0-b105
Intel Core 2 Duo T5300
1 GB of RAM
Ati X1400 @ 1280x800 32bbp

Both machines:
- dual-core with speed throttling and power saving technology
- use the classic desktop
- tried running Processing with no other Java apps or software.
- checked and unchecked pref. - set max available memory to, 256 - 400 MB
- it's more likely to occur with bigger window sizes or heavy initialization.
- smooth() is being disabled when it occurs.

I'll try to post the errors I get from the XP machine when I get home tomorrow. It
sometimes outputs thread related errors even if the sketch and window size are
working fine.
Additional Comment #10 From fry 2007-07-22 13:06
any virus scanning software installed? systemworks-type stuff? traffic
monitor? windows or other firewall?
Additional Comment #11 From Bas 2007-07-22 15:02
Nope, sorry, just the Windows firewall. I don't have any virus or system type stuff
running in the background. The list of processes and services is very short on both
systems. Cpu usage at idle is practically 0 and there's plenty of free memory.

It makes no difference if I use Illustrator and VVVV at the same time or not.

I could try to set the priority of Processing higher? Run some heavy system type
stuff to see if it's more reproducible? Assign the Processing javaw.exe process to just
one core? Set java to just use one core if that's possible?
Additional Comment #12 From Bas 2007-07-23 10:09
From my Windows XP system. Sketch and window size are OK when I get these.
1.5GB of available memory.

On close/stop sketch window:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
at java.lang.Shutdown.runHooks(Unknown Source)
at java.lang.Shutdown.sequence(Unknown Source)
at java.lang.Shutdown.exit(Unknown Source)
at java.lang.Runtime.exit(Unknown Source)
at java.lang.System.exit(Unknown Source)
at processing.core.PApplet$4.windowClosing(PApplet.java:6738)
at java.awt.Window.processWindowEvent(Unknown Source)
at java.awt.Window.processEvent(Unknown Source)

While a sketch is running:
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start(Native Method)
Additional Comment #13 From fry 2007-07-23 19:51
that's a new one.. i've never heard of that showing up. tough to say
whether it's related or not.
Additional Comment #14 From ali_mi 2007-08-07 19:57
I have the same problem on WinXP SP2 with the following hardware:

Intel P4 D930 Dual 3.0GHz
ASUS P5LD2 Deluxe LGA775
2GB DDR Kingston
250GB HDD Seagate
ATI FireGL V5100

It happpens most of the time, so practically Processing cannot be used on this

Additional Comment #15 From ali_mi 2007-08-07 20:11
This could also be a related bug, I'm not sure. When I run the code:

void setup(){

void draw(){

The output will be:

It appears like draw() is called twice and the "width" value is set to 128 somehow.
This happens for "width" values less than 128 and results all graphics calculated
according to the "width" value to be distorted.
Additional Comment #16 From fry 2007-08-28 18:58
that's very, very strange but also likely a clue. it gives me some ideas
about things to check.
Additional Comment #17 From fry 2007-09-30 06:07
*** Bug 630 has been marked as a duplicate of this bug. ***
Additional Comment #18 From fry 2007-10-16 06:32
fixed for 0128, i think/hope/pray.