graphics api results in tcl errors in console on Windows

[sebshader]

On windows 10 (Tcl/tk 8.6.13 Pd 0.54-1) when using the introductory help file and the new gui example there are errors in the console:

(Tcl) UNHANDLED ERROR: unknown option "-font"
    while executing
".x71416d90.c itemconfigure {.x13146} -font {{DejaVu Sans Mono} 8 {bold} } -fill {#FC7651} -justify {left} "
    ("uplevel" body line 53)
    invoked from within
"uplevel #0 $docmds"

the canvas item tag varies and sometimes only has 3 or 4 numerical digits. (e.g. {.x888}) this also happens for lines 35, 38, 41, 53, 56, 104

there is also

(Tcl) UNHANDLED ERROR: wrong # coordinates: expected 0 or 4, got 22
    while executing
".x71416d90.c coords {.x16505} 318 222 323 236 338 236 326 244 332 258 318 249 304 258 312 244 300 236 315 236 318 222 "
    ("uplevel" body line 26)
    invoked from within
"uplevel #0 $docmds"

[agraef]

The first one is at pdlua_gfx.h:1020, the second one apparently at pdlua_gfx.h:1179.

I have the same version of both Tcl/Tk and Pd on my Linux box, but I don't see any of these errors, so I'm not sure what's going on there. @timothyschoen Can you help?

[agraef]

@sebshader How did you install the latest pd-lua revision, did you grab the Windows build from here?

[agraef]

Also, what's the pd-lua version number shown in the console? It should be pdlua 0.11.6-82.

[agraef]

the canvas item tag varies and sometimes only has 3 or 4 numerical digits. (e.g. {.x888})

That's something with the item tags being generated by the gfx routines via register_drawing(), if I'm not mistaken. @timothyschoen It seems that those numbers are generated using rand(), maybe that's not such a great idea? Works on Linux, but not on Windows/mingw where rand() probably is a system function which is potentially much less well-behaved than on Linux?

[agraef]

Maybe it would be better to create some unique hash for each gfx object, something like a uuid maybe? How do you handle that in the plugdata gfx code?

[sebshader]

@sebshader How did you install the latest pd-lua revision, did you grab the Windows build from here?

no I compiled master with latest mingw (gcc)

edit: it just says pdlua 0.11.6

[sebshader]

I tried to put a debugging line before:

object tag: .xcdd3cb60, register: .x31695
(Tcl) UNHANDLED ERROR: unknown option "-font"
    while executing
".xcdd2f6d0.c itemconfigure {.x31695} -font {{DejaVu Sans Mono} 8 {bold} } -fill {#FC7651} -justify {left} "
    ("uplevel" body line 57)
    invoked from within
"uplevel #0 $docmds"

most of the debugging lines print fine without any error though. I'm blaming microsoft like I do with everything else

[sebshader]

I think I agree that the best guess is that the canvas is hanging onto or reusing old object tags somewhere and creating some kind of collision edit: there was just a case where the console errored on a tag that had already been used. I'm not sure why it would be an issue if the item has been deleted though..

[sebshader]

it also sometimes happens that items get written in black to the canvas the object is on and stay there if I move the gui object. dunno if related..

[timothyschoen]

I'm now testing on Windows, and there are a few issues indeed:

I can confirm @sebshader's bug regarding the error messages, it seems to happen when configuring the font, which is probably also why the text is rendered huge:

@agraef I agree that the random string generation is terrible, I have a fix for this now. It doesn't solve this bug yet though.

[timothyschoen]

Making progress, the problem did seem to arise with the random generation. Seems like rand() on Windows/MinGW is indeed not reliable. The error messages are now gone, simply by using:

unsigned long long custom_rand() {
    static unsigned long long seed = 0;
    const unsigned long long a = 1664525;
    const unsigned long long c = 1013904223;
    const unsigned long long m = 4294967296;  // 2^32
    seed = (a * seed + c) % m;
    if(seed == 0) seed = 1; // We cannot return 0 since we use modulo on this. Having the lhs operator of % be zero leads to div-by-zero crash on Windows

    return seed;
}

I'll clean up my code and send a PR for this fix!

It appears the huge text I get is caused by my hi-dpi screen. If I disable display scaling, it's fixed. Seems like pd-vanilla receives information about font size on startup, in the glob_initfromgui function. We will need to use this information to correctly scale our text rendering. (edit: looks like we need sys_hostfontsize)