eessppeelllloo/processing4
1
0
Fork 0
mirror of https://github.com/processing/processing4.git synced 2026-02-14 19:05:34 +01:00
Code Issues Packages Projects Releases Wiki Activity

add notes about getComponent()/getCanvas()

Browse Source
This commit is contained in:
Ben Fry
2015-05-13 09:25:46 -04:00
parent 9d17ac383a
commit c826bf2744
2 changed files with 7 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
core/README.md
View File

@@ -20,6 +20,11 @@ We're removing `Applet` as the base class for `PApplet` and redoing the entire r
1. One downside is that you'll no longer be able to just drop a Processing sketch into other Java code, because `PApplet` will no longer subclass `Applet` (and therefore, `Component`). This is a huge downside for a tiny number of users. For the majority of users, re-read the "why" section. We'll try to figure out ways to continue embedding in other Java code, however, since we use this in our own work, and even within Processing itself (the Color Selector).
2. We're still determining how much code we're willing to break due to API changes. Stay tuned.
#### Integration with Java applications
Because `PApplet` was a Java `Component`, it was possible to embed Processing into other Java code. Making it a generic component, however, places limitations on how much performance can be improved, due to the cross-platform mess of Java's outdated (and somewhat unsuspported) AWT.
In earlier alpha releases, a `getCanvas()` or `getComponent()` method provided a way to get an object to be embedded, but at the current time, it looks like we'll have to move in another direction. At the present time, it looks like it'll be necessary to create a separate `PComponent` or `PCanvas` class that can be used, but it's not clear how that will work.
This is one of many unfortunate tradeoffs I'm trying to sort through as we try to remove significant barriers to performance caused by the design of Java's AWT, while also supporting features (like embedding) that we've spent so much time supporting.
#### Offscreen rendering
* createGraphics() will create a buffer that's not resizable. `PGraphics.setSize()` is called in `PApplet.makeGraphics()`, and that's the end of the story. No `Surface.setSize()` calls are involved as in a normal rendering situation.

2
core/todo.txt
View File

@@ -31,6 +31,8 @@ _ shouldn't be static, run it from the renderer, that's point of createXxx()
_ when did setPath() sneak into PShape? API is nothing like anything else
_ public createShape() method that takes another shape as param?
_ should just be the constructor doing this, or copy()
_ drawing 100k lines is slow (example from Reas)
_ figure out what the bottleneck is here
high priority