setContext()

General
#1

Just feedback on setContext(), upcoming: I love it.

But you’ve managed to, with a single command, make useless most of my Pic() library. :slight_smile: (That is NOT a complaint - this is a Good Thing)

So - let’s talk about what’s not useless (yet) - a Flood Fill, and the ability to draw arbitrary filled (or unfilled) polygons. Both are (were) pretty easy to write, but are slow (compared to native commands) in execution, because I have to do things pixel by pixel (not 100% true - I need to mess with it, but I think I can do lines in each instead of pixels).

But the demand is much lower now - I’m instead simply going to suggest that unlike my other suggestions (SOCKETS!), a flood fill and/or arbitrary polygons (filled and unfilled) would be Good to Add and Apple Approved. (I guess I could get a triangle with careful application of clip() and rect and rotation, and then draw other shapes with those triangles, but bleargh)

Also missing is image import (by this I mean jpg/gif/png), but without sockets to fetch them, that’s not nearly as exciting, due to difficulty getting data into the app itself. Sigh.

#2

I have been trying to image what this new function will do (based on your post in another thread) but can’t say I have been very successful.

Thus pray tell if you will sir.

#3

you do something like

setContext(myImage) --tell codea to draw into your image instead of on the screen
rect() etc, other drawing commands
setContext() --reset codea to drawing on the screen
sprite(myImage)

This will draw your image of what you drew before into the scene, you can draw this multiple times, at different scales, or get/set the pixels then draw it (ie, you could do a blur, or other fancy transformations)

#4

Thanks Dylan, that’s a bit clearer.

#5

So from a practical standpoint, this lets you draw into an image that you can then scale/stamp onto the screen the viewer sees.

What does that mean? Well - a really complex image could be drawn, buffered, and simply drawn to the screen with a single sprite() call - much faster than, say, 1000 line() calls.

it also means image compositing - you could build that image() out of sprite() calls, rather than pixel setting.

#6

Thanks Mr. B. it’s what I had hoped for… the possibility to create sprites with the graphic primitives (rect(), ellipse(), line()) rather than pixel by pixel.

1.2.7 has certainly got some good cheer to raise the dampened holiday spirit!