-
• #27
I think (with a SAVE_ON_FLASH ifdef) it's something that could make sense to put in (after all we do have
zigzag
mode in there).Do you have a link to the code you used?
-
• #29
Thanks - that drawEllipse stuff looks great and I'll get that added, but I really don't want a whole new ArrayBuffer implementation shoved in the head of graphics.c when I'm pretty sure it could have been a 2-liner in https://github.com/espruino/Espruino/blob/master/libs/graphics/lcd_arraybuffer.c#L20 as I'd suggested? I'll see what I can add.
-
• #30
The better solution always beats the best.
To be honest, I've had no idea how to do as you suggested.
So lets wait and I will see (learn) -
• #31
I notice in your solution you're writing pixels as what's basically
0x00rgbrgb
. Do you see anything wrong with doing0x0rgb0rgb
? It just makes it a slightly more flexible as then the function could be used for overlapping graphics of any number of bits per pixel. As it is I'd be allocating 4bpp, but shifting by 3bpp.To shift out you'd use
[R1,G1,B1,undefined,R2,G2,B2]
rather than[R1,G1,B1,R2,G2,B2]
. It's not perfect but IMO it'd make it less of a single-use piece of functionality. -
• #32
I don't see any problem with 0xrgb0rgb
-
• #33
Great! Just committed:
>g=Graphics.createArrayBuffer(64,32,4,{interleavex:true}) =Graphics: { buffer: new ArrayBuffer(1024) } >g.setPixel(0,0,7);print(g.buffer) new Uint8Array([7, 0, 0, 0, 0, 0, .... =undefined >g.setPixel(0,16,7);print(g.buffer) new Uint8Array([119, 0, 0, 0, 0,....
Hopefully that'll work for you - and who knows, maybe it'll end up being useful for something else later on :)
-
• #34
Also, just added your ellipse code. I modified it so that it takes x1,y1,x2,y2 so that it can be called in the same way as fill/drawRect - it also works better with
graphicsToDeviceCoordinates
because as it was it would have broken when used with rotated screens.However, it seems there are some issues... I'd expected that
drawEllipse
with width and height the same would draw something that looked the same if you rotated it by 90 degrees - that doesn't seem to be the case?
https://github.com/espruino/Espruino/blob/master/tests/test_graphics_ellipse.js#L22Also - and this one's my fault - because you can now specify the bounding rect you can effectively ask it to draw something that doesn't have an integer radius. I don't know if that's something that can easily be fixed with that algorithm? No worries if not :)
-
• #35
@Gordon I've checked with
shiftOut.bind(null,[R2,G2,B2,undefined,R1,G1,B1],{clk:Clock}); .... Graphics.createArrayBuffer(64,32,4,{interleavex:true});
setPixel, drawLine work fine,
but fillRect, drawRect, clear, drawCircle, fillCircle don't. Some pixel are at wrong places,
Data in buffer is wrong, easy test isgr = Graphics.createArrayBuffer(64,32,4,{interleavex:true}); gr.setBgColor(1) ; gr.clear(); console.log(new Uint8Array(gr.buffer,64,64));
Rotating of Ellipse, hmm no idea, I've to check. But Christmas is coming, and family is coming, ....
-
• #36
Oops - forgot about the fills. Try now!
-
• #37
Works perfect now!
Thanks a lot and have a nice christmas.
I've checked your version and it takes about 0.16s on ESP32.
I agree, ESP32 its not the fastest on earth.
Anyway, this results in a black led-panel for a remarkable time, before new data is available.
To get a better idea what a setPixel driver in C could be, I created a version for testing. All together it is about 25 lines including initialization. Switching to this driver is done by adding panel:true to config of createArrayBuffer.
Wow, now a clear() takes less than 2msec. And I was able to create some kind of simple animation using graphics class.
I wonder, how we could add this to Espruino. It is specific for these kind of boards (P2.5,P3,P4,P5). It is not as specific as Neopixel, where we need implementation for each board. So it would be available for all boards.
My ideas behind using this panels are things like: