On Feb 14, 2011, at 8:51 50PM, laurent laffont wrote: > On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <[email protected]> wrote: > On 14 February 2011 18:45, laurent laffont <[email protected]> wrote: > > Today: ColorMappingCanvas > > > > As far as i understood, this class is abstract, and its subclasses > implement more specific behavior > - shadow > - semitransparency mapping > > > The idea of is kind of canvas is to modify/filter the final output in > rendering pipe.. > i.e., for each potential pixel operation like: > > source -> op -> output > > it introducing a color mapping stage: > > source -> op -> mapping -> output > > > So, then for instance you could make a subclass which could turn all > colors to be grayscale (disregarding that initial input was in > colors). > > in fact i think this guy took wrong direction. It is much more > effective to let the canvas to draw whatever it wants to some > backup/temporary surface, and once it done, simply blit + color-map > result to destination form using one, single strike. > > > ah ah, it seems last COTDC are: > - this class is bad written > - this is not used > - nobody understand > > still lot of work ;) > > Laurent
ShadowCanvas is used in the Glamour theme when fastDragForMorphic is disabled. Cheers, Henry PS. You'll see a noticable increase in dragging performance (at least on non-Cog vms)if you change configureWindowBorderFor: to return a non-translucent value. This is because wantsToBeCachedByHand returns false when the morph isTranslucent. I don't really think the restriction makes much sense, a canvas should have no problem drawing a cached image with translucency, but changing it probably includes revisiting how paint rules are chosen, which will be a huge pain for whoever does it.
