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.

*** This bug has been marked as a duplicate of 195 ***

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.

*** Bug 516 has been marked as a duplicate of this bug. ***

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:
Code:

void setup(){

size(600, 300);
size(600, 300);
size(600, 300);
frameRate(30);

}

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):

Code:

try { Thread.sleep(50); } catch (InterruptedException e) { }

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)

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.

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.

(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?

Here are my specs:

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

II
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.

any virus scanning software installed? systemworks-type stuff? traffic
monitor? windows or other firewall?

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?

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)

that's a new one.. i've never heard of that showing up. tough to say
whether it's related or not.

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
machine.

This could also be a related bug, I'm not sure. When I run the code:

void setup(){
size(100,200);
noLoop();
}

void draw(){
println(width);
println(height);
}

The output will be:
100
200
128
200

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.

that's very, very strange but also likely a clue. it gives me some ideas
about things to check.

*** Bug 630 has been marked as a duplicate of this bug. ***

fixed for 0128, i think/hope/pray.