NoClear() extension: NPE when program window is minimised

[CodeCox]

OS:Windows 10
Program: NoClear.kt

Here's the exception log. The first two lines are from my debug println's. It shows the change in the default window co-ordinates when it is minimised:

...
width=640 , height480, win-pos=Vector2(x=320.0, y=120.0)
width=0 , height0, win-pos=Vector2(x=-21333.333333333332, y=-21333.333333333332)
java.lang.IllegalArgumentException: unsupported resolution (0×0)
	at org.openrndr.draw.RenderTargetKt.renderTarget(RenderTarget.kt:92)
	at org.openrndr.draw.RenderTargetKt.renderTarget$default(RenderTarget.kt:90)
	at org.openrndr.extra.noclear.NoClear.beforeDraw(NoClear.kt:27)
	at org.openrndr.Program.drawImpl(Program.kt:233)
	at org.openrndr.internal.gl3.ApplicationGLFWGL3.drawFrame(ApplicationGLFWGL3.kt:534)
	at org.openrndr.internal.gl3.ApplicationGLFWGL3.loop(ApplicationGLFWGL3.kt:475)
	at org.openrndr.Application$Companion.run(Application.kt:29)
	at org.openrndr.ApplicationKt.application(Application.kt:69)
	at org.openrndr.ApplicationBuilderKt.application(ApplicationBuilder.kt:26)
	at SketchKt.main(Sketch.kt:6)
	at SketchKt.main(Sketch.kt)
Exception in thread "main" java.lang.IllegalArgumentException: unsupported resolution (0×0)
	at org.openrndr.draw.RenderTargetKt.renderTarget(RenderTarget.kt:92)
	at org.openrndr.draw.RenderTargetKt.renderTarget$default(RenderTarget.kt:90)
	at org.openrndr.extra.noclear.NoClear.beforeDraw(NoClear.kt:27)
	at org.openrndr.Program.drawImpl(Program.kt:233)
	at org.openrndr.internal.gl3.ApplicationGLFWGL3.drawFrame(ApplicationGLFWGL3.kt:534)
	at org.openrndr.internal.gl3.ApplicationGLFWGL3.loop(ApplicationGLFWGL3.kt:475)
	at org.openrndr.Application$Companion.run(Application.kt:29)
	at org.openrndr.ApplicationKt.application(Application.kt:69)
	at org.openrndr.ApplicationBuilderKt.application(ApplicationBuilder.kt:26)
	at SketchKt.main(Sketch.kt:6)
	at SketchKt.main(Sketch.kt)

Process finished with exit code 1

It fails on this line because width/height is 0

 renderTarget = renderTarget(program.width, program.height) {
                    colorBuffer()
                    depthBuffer()
                }

I'll submit a PR to fix this NPE. (However, width & height contraints still needs to be considered for the whole application!)

[CodeCox]

Some thoughts (probably more for my benefit!)

• width & height can be set to 0 by window events e.g. size, minimise. What else?
• What is the valid range of values for width & height? Any value > 0?
• Program Configuration in Guide

configuration {
    width = -1
    height = -1
    fullscreen = true
}

The program crashes if fullscreen is omitted. Perhaps width and height should not be used like this with negative values to convey another intent? There's probably no overhead in using another (new) attribute to indicate this config choice?

• The drawing functions seem to 'gracefully' handle width & height of 0 when the window is minimised. (How?)

drawer.circle(Random.nextDouble() * 640, Random.nextDouble() * 480, 10.0)

even the following does not fail even though arguments of 0 were probably not intended.

drawer.circle(Random.nextDouble() * width, Random.nextDouble() * height, 10.0)

but unsurprisingly kotlin Random() fails with this invocation.

drawer.circle(Random.nextDouble(0.0, width * 1.0), Random.nextDouble(0.0, height * 1.0), 10.0)

So some consideration must be taken with the usage of width & height?

[edwinRNDR]

@CodeCox you bring up some interesting points, some of which I have run into myself. Most of these are issues for OPENRNDR so we should move to conversation there at some point.

Currently a RenderTarget should be at least 1x1 pixels (although I think there is a minimum OpenGL texture size of 16x16).

Question is if a Program should have their draw() function called if the window is minimized or otherwise has a 0 pixel area.

The fullscreen configuration should be reconsidered, instead of a boolean option it could use sealed classes and have clear WINDOWED / CURRENT_RESOLUTION / SET_RESOLUTION modes instead of the -1 width/height magic it currently uses.

[CodeCox]

Question is if a Program should have their draw() function called if the window is minimized or otherwise has a 0 pixel area.

It's a non-trivial question - needs to be dissected further (apologies for the digression )

• The draw() loop is the heart - its not only for drawing, pausing this will temporarily stop everything? Except already initiated callbacks and async threads? Some callbacks like the keyboard listener definately must be still be active viz. it could restore the display window. Some functions (in async threads?) may not be dependant on the state of the display window e.g drawing to off-screen buffers.
• There's no point in drawing to 0 pixel areas. Even a 1x1 area sounds implausible to me. But then what is a practical value for this lower limit?
• At first glance, there's no point in drawing to the program display window if it is not visible. But what if you want a long-running sketch to progress in the background without actively watching a frame-by-frame account e.g. generative art, reading(graphing) a sensor once every hour. You already have manual and headless presentation modes to provide some choice. Minimising a window may be a practical way of letting the application do its thing in the background.

The draw() loop going full blast as it does now is great for some situations e.g time critical visualisations, livefeeds, etc. But it is also a huge drain on resources. In many cases this over-consumption is unnecessary.The framework could do with 'throttle' and 'brake' features but it would have to be configurable (with recommended defaults).