On Apr 18, 2010, at 11:57 PM, Bert Freudenberg wrote:
On 18.04.2010, at 20:14, stephane ducasse wrote:
Thanks Bert
I think only the first 4 inst vars are actually used by the plugin:
http://squeakvm.org/svn/squeak/trunk/platforms/unix/src/plugins/RomePlugin/R... #define CanvasHandleIndex 0 #define CanvasTargetIndex 1 #define CanvasFlagsIndex 2 #define CanvasStrokeColorIndex 3 #define CanvasInstSize 8
how did you get that information? from the image side or C code? Because I tried to see but unsure.
It's in the C code I linked above. I just reordered it for better readability.
Yes I saw my question was more how do we identify code that is not used anymore? We just do the closure over the published primitives and the rest means that it is useful. My question was how did you identify that only 4 inst were used and not more.
The proper fix would be to modify RomePlugin class>>initializeInstVarIndices to not generate the indices, but simply hard-code only the used ones (setting CanvasInstSize to 4), and change the comparison John mentioned below to <=. Also remove the unused *Index class vars. Now that there are plugins in the wild, hard-coding the indices is a good idea anyway. During development, the flexible generator version was useful, but not anymore.
Ok I will browse the RomePlugin class with Cyrille and Jean-Baptiste
I browsed a bit the C code and I'm learning so may be my questions are not clever, but
- do we need the pango primitives for ROME? Apparently Pango may use Cairo for fonts rendering but do Rome needs that? So is it simpler to use fonts via pango than cairo.
Pango provides word/paragraph layout. Many non-latin scripts (e.g. Devanagari) require "glyph shaping", there is no one-to-one mapping between Unicode characters and glyphs rendered in context. Pango can do that. I'm not aware of any other renderer in Squeak that would support this (Yoshiki added it for OLPC). Well, maybe the Unicode plugin from Scratch could do it too, not sure.
- then what about FormInstSize?
(interpreterProxy->slotSizeOf(formOop)) < FormInstSize does it mean
Same thing. The instance variables actually used by the plugin should be hard coded. Otherwise the same would happen as in Sophie - some inst vars were added to the Canvas, so the inst size compiled into the plugin became larger than necessary.
Btw, by now you probably have guessed that a workaround for the Mac issue would be to add 5 dummy inst vars to RomePluginCanvas just to make the plugin happy.
Yes. In fact my question was more is FormInstSize used (or are the functionality using FormInstSize used)? I have problems to see how we can clean the C code. All my questions should be interpreted with this slant.
It doesn't need to be "in sync". But maybe I do not understand the question.
Sorry was not clear. My question is how Cairo supports backwards compatibility? What happens if the plugin expect a different version of Cairo on the machine? May be they do not change their interface? Stef