 |
Author |
Topic: java.awt.Shape support (Read 2560 times) |
|
Ricard
|
java.awt.Shape support
« on: Feb 2nd, 2005, 10:20pm » |
|
Hi,
I'm having trouble rendering a java.awt.Shape object using the P5 functions. I know that Processing must stay a sketching language and to the reach of non-programers. I was wondering if a java.awt.Shape renderer and/or equivalent would be an interesting addition to P5.
Although I understand this might be a very punctual problem, in that case, is there an easy way to render that type of class/structure in processing (personally I don't know how to render the outline "SEG_QUADTO" and how to fill the shape using the constants "WIND_EVEN_ODD" and "WIND_NON_ZERO" given by a java.awt.geom.PathIterator).
Some points about this suggestion:
- It may not be so hard? since using Processing we can render fonts, and fonts are shapes.
- This complicates the language? but aren't shapes very important concepts for artists.
Thanks,
ricard
|
|
|
|
|
fjen
|
Re: java.awt.Shape support
« Reply #1 on: Feb 3rd, 2005, 1:39am » |
|
ricard,
you can draw "SEG_QUADTO" by treating it's one control-point as two. just use it twice and pretend it's a "SEG_CUBICTO". not sure that's mathematically 100% correct though ...
( look at this picture and consider the one point at the top of the quadric bezier (left) to be the two top-points in the cubic one (right) moved onto one another ... )
i'm against supporting java's awt.Shape for several reasons:
- it's very easy to implement your own shapes in processing, easier than using the java interfaces
- it would make Processing-language too complicated
- yes, shapes are important, so why stick to someone else's (limited) implementation? (free shapes!) 
- since processing is based on java you can already use the awt.Shapes now
btw: processing-fonts (vlw) are pixel-based!
/F
|
| « Last Edit: Feb 3rd, 2005, 1:50am by fjen » |
|
|
|
|
Ricard
|
Re: java.awt.Shape support
« Reply #2 on: Feb 3rd, 2005, 2:15am » |
|
Hi fjen,
Thanks again for your cooperation. It's really helpful, I will try your little trick for the SEG_QUADTO.
And maybe you are right about not being a good idea of supporting java.awt.Shape in processing, because Processing is built over Java.
I still find it hard to do composition of paths (adding paths, intesecting,...) in P5. But it could also be the need of practice, jejeje.
So I'll keep working.
thanks
ricard
|
|
|
|
|
fjen
|
Re: java.awt.Shape support
« Reply #3 on: Feb 3rd, 2005, 3:10am » |
|
you're welcome. you might want to try a modification of "my trick": doubly use the endpoint ... the curve might look better then.
as to the awt.Shape, well that's just my point of view. there's a thin line between usefulness and bloating. think about major tools like illustrator for example, i hardly use 10% of what's in there, so why do i need the rest and why would i have to pay for it? features seemed to be a major motor of sales, but i disagree there. i think a tool should be as useful, as user-friendly as possible and maybe open to a certain degree (scripting). ... for me that's one of the beauties of processing, it does very well what it's supposed to do and if i need more i'll add it myself. but again, that's just my point of view.
/F
|
|
|
|
|
fry
|
Re: java.awt.Shape support
« Reply #4 on: Feb 11th, 2005, 9:01pm » |
|
we won't be supporting java.awt.Shape because it's only available in java 1.3 and higher, and at least half of net users are still using java 1.1. it's also very poorly designed (for our use), like most of the rest of java2d, which is the other reason why we did our own api entirely for processing.
ideally we'd like to add a nice shape api to that makes it easier to draw shapes than just beginShape() et al, but we haven't gotten around to it.
|
|
|
|
|
Ricard
|
Re: java.awt.Shape support
« Reply #5 on: Feb 14th, 2005, 11:47pm » |
|
I agree with you very much, in making the Processing resulting applets. So I think it's a good idea to discard the support of java.awt.Shape.
I also think it would be nice to support that kind of command (beginShape()) since in my case I'm finding it quite hard to make complex shapes (like glyphs).
In the same line, if the class is not supported, is there another way of accessing the control points of vectorial fonts from processing.
And finnally. I don't know too much of the deceloppement of processing (read about the status, but don't know if there's a dev mailinglist or some people in charge of some pieces of the API), anyway I would like to help with the engineering background I have. But of course it's ok if you find it unnecessary or just not useful at the moment.
cheers,
ricard
|
|
|
|
|
|
