first of all, great time in barcelona. thanks to everyone who participated, it was great to spend time with you all. and of course thanks to the people who helped set it up (jose luis, pedro, hangar, offf, and on and on), should they happen to read things here.

as is usually the case when mr. reas and i get a chance to work together in the same city (usually outside of the states and horribly jetlagged), we do lots of decision making for the project, and get some concentrated time to work out some of the nastier details of things.

so here's the outline of what we've decided, as we plan for a 1.0 release:

+ support for P2D will return in the same form as was in the alpha releases. that means the 2D renderer from 0068 and 0069 will be returning. if you want accuracy--like stroke caps and joins and thick outlines on a circle that don't look like a caterpillar, you can use JAVA2D, which will remain the default (probably).

+ loadPixels and updatePixels, the bane of our beta transition must remain. for P2D and P3D they won't be necessary, but for JAVA2D and OPENGL they will. this is simply an unfortunate thing for the way things must work in order to be fast enough.

+ our plans to do something with antigrain for nice 2D will happen post-1.0.

+ loadPixels and updatePixels will be renamed beginPixels and endPixels, in an attempt to 1) be clearer, because the whole load/update thing seems to be confusing as hell for people.. basically the rule being, any time you mess with pixels[], you put a begin/end around it.

+ for people playing with other renderers and offscreen buffers.. defaults() will go away, but beginDraw and endDraw will be required, and will replace beginFrame/endFrame, if by chance you were using that before. again, this serves the purpose of standardizing the api, and being clearer.. i.e. it was weird to use beginFrame() and endFrame() on a PGraphics created with createGraphics inside of setup when you're not really drawing a frame. so beginDraw/endDraw will just mean "i'm about to do commands like i normally would inside draw()".

+ a PShape object will be introduced, that will contain vertex and shape data. this will initially not be exposed directly until we get a chance to iron it out internally, but will be appearing soon. this will eventually be the repository for 1) your own shapes stored as a hierarchy 2) svg-loaded data 3) obj-loaded data. not sure which of these will be essential for 1.0, though #2 seems to be a priority.

+ PGraphics2 will become PGraphicsJava, to make way for P2D. PGraphics will become a more abstract class that handles grunt work for other PGraphics subclasses. better docs will be written on how to write your own extension to PGraphics.

+ we're trying to figure out a way to have the transition not suck as much as the transition from alpha to beta. perhaps load/updatePixels will throw an error asking "would you like me to fix this?" and the same for things like beginFrame becoming beginDraw.. though it's not clear how many people are using this kind of thing, and whether it's just advanced users who read the board anyway.

+ beginShape() modes for POLYGON, LINE_LOOP, and LINE_STRIP will be merged into a single beginShape() with no parameters (beginShape() with no params was formerly POLYGON). basically there's an inconsistency to how these work, and they refer to the same things. when you want a filled polygon, you'll need to close the thing off (return to the first point) and when you don't, just leave it open. but it's something we need to specify in the api so that we can make assumptions about how the polygon tessellator will work and to get those bugs fixed.

+ better docs for PDF and createGraphics() are on the way. lots of bug fixes for begin/endRaw and begin/endRecord are in the pipe as well.

i think we'll be holding off on additional releases until we can do all the api changing stuff at once (a couple days, weeks?) so that we aren't changing api between releases the way we did back in the alpha days. aahh the alpha days. one tenth the number of angry users. we could pull almost anything back then.. sigh..

if you're bummed about the api changes, just be happy that casey and i caught ourself after an initial discussion of changing vertex/bezierVertex/curveVertex over to moveto/lineto/curveto/splineto. i think i was smoking the abstraction hookah while reading the over-architected 750 page svg spec. it was weeks before my head cleared and i realized the change would be a mess.