From Gnash Project Wiki
= point1: pixel units(PIXEL or TWIPS)doesn't necessarily make different coordinates spaces, just a matter of scaling.
Udo: "coordinate system" may be not the correct mathematical term, but I think it will help when talking about coordinates, as a replacement for a unique unit for each scaling
= point2: check how many extra matrices we need in addition to those defined in SWF files first.
Udo: one for each "coordinate space"
- strk: zou was talking about "in addition to those defined in SWF files". The SWF contains all statically-defined coordinate spaces (timelines?). In addition to them we have the GUI/Renderer coordinate space, which I belive is the only (or only two) *additional* ones.
= point3: one single transformation matrix used for framebuffer to GUI conversion is enough for all the things.
Udo: coordinate translation core<-->mouse and core<-->renderer is done frequently. We should have a matrix ready for each of these situations as concatenating a matrix is generally faster compared to a matrix xform + following scaling.
- zou: (1)mouse pointer's coodinates should be already transformed to GUI space(player window) by the mouse driver, so I guess there should be no extra matrix for mouse to core translation(keep it simple).
- zou: (2)core to renderer convertion doesn't need to be bidirectional. The model from core to renderer is:
input1: shapes in defintion(defined by swf or AS) input2: shapes transformation matrix from VM(defined by swf or AS) input3: shapes transformation matrix from GUI(definded by the Player) given input1,2,3, the renderer should have enough information to draw all shapes to the framebuffer. Or the renderer need to do more things than just drawing?
- I agree we should have a matrix ready for those.