On 7 April 2016 at 13:10, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-07 11:15 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 7 April 2016 at 10:32, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 17:07, Nicolai Hess <nicolaihess@gmail.com> wrote:
2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguctua@gmail.com>:
On 6 April 2016 at 11:36, Nicolai Hess <nicolaihess@gmail.com> wrote:
Thanks Igor. Maybe some more Info? (I don't have much experience with this and don't fully understand what is missing).
1. No support for vector graphics
I know some parts of Athens (with Cairo font renderer and how it is used in TxText) but at the moment rendering a TextMorph in Athens works: Morph comment asText asMorph openInSceneView
Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface.
Nah, actually it works a bit different. Many (Form)Canvas methods are reimplemented on Athens API. But yes, I used some hacks as well.
Didn't knew. Aha.. i see AthensCanvasWrapper. Ohh.. that's so much pain :)
As you are here and in a good mood for feedback, can you please answer some Athens questions or review some code changes / issue entries?
I added some instance variables for AthensCairoPatternPaint (origin, extent) This was needed for converting Morphics GradientFillStyle to Athens pattern paint. But I am unsure if this was the intended way to use them.
There are protocols for creating gradient paints in Athens:
createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint createRadialGradient: colorRamp center: aCenter radius: aRadius focalPoint: fp
how you storing things inside or transform this information is orthogonal. From that perspective, anything what happens in AthensCairoPatternPaint is implementation detail. If you think that this protocol is not sufficient to define gradients, then fix it.. What happens on concrete implementation is last thing that should worry about.
From my POV , two points and color ramp is enough to define linear gradient. Things like extent is a derived data, that can be obtained via simple calculations from original data. That why it wasn't there in a first place.
I am interested on issue
14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior is on purpose ,but I am not sure).
The intent was to make clipping work with Morphic..
Hm, I still don't know if the outcome was intended. If you compare the two example codes, the first defines a cliprect translates the path transform draws a rectangle (the green one), this rectangle is clipped (that is, the cliprect is not translated - OK)
The second example does the same, but defines again a cliprect after the path transform. Now the rectangle is not clipped (by the first clip rect), although the comment in AthensCanvas says "Note that the clipping rectangle is intersected with the currently active clipping rectangle"
If i remember the intent was to demonstrate that you can nest clipping operations. Ideally that should work as: - you clip in local coordinates - then you can translate/transform coordinates again - and again clip, but in new coordinates, but that still take into account the outer clipping. IIRC, Cairo doesn't allows nesting for clipping.. but i may be mistaken. -- Best regards, Igor Stasenko.