Today: ColorMappingCanvas
Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s).
#2: If you cannot comment it, deprecate it. Laurent |
On 14 February 2011 18:45, laurent laffont <[hidden email]> 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. -- Best regards, Igor Stasenko AKA sig. |
On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <[hidden email]> wrote: On 14 February 2011 18:45, laurent laffont <[hidden email]> wrote: ah ah, it seems last COTDC are: - this class is bad written - this is not used - nobody understand
still lot of work ;) Laurent
|
On Feb 14, 2011, at 8:51 50PM, laurent laffont wrote:
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. |
In reply to this post by laurent laffont
Just a thought...
Note that, by default, for a window with a model
object... the "About" window menu option
will show the class comment for the
model.
Once we have all classes commented, it might be
nice to review existing comments (long job)!
Try on a SystemBrowser, for instance... quite
cryptic!
Regards, Gary
|
In reply to this post by Igor Stasenko
So the comment I propose mixing what you said with my understanding: I'm an abstract class which introduce a filter between a drawing request and the final output, handled by #mapColor:
For each potential pixel operation like: source -> op -> output
it introducing a color mapping stage: source -> op -> mapping -> output Then #mapColor: can be redefined in subclasses to implement more specific behavior. For example: - ShadowDrawingCanvas will replace the rendered color with the color of shadow (if not transparent). - AlphaBlendingCanvas will add or intensify alpha of rendered color. For an easy to understand example see #drawPolygon:color:borderWidth:borderColor:
ShadowDrawingCanvas: see ColorMappingCanvas comment.
AlphaBlendingCanvas: see ColorMappingCanvas comment.Laurent. On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <[hidden email]> wrote: On 14 February 2011 18:45, laurent laffont <[hidden email]> wrote: |
In reply to this post by Gary Chambers-4
On Tue, Feb 15, 2011 at 6:09 PM, Gary Chambers <[hidden email]> wrote:
oh.... do you have a script to detect automatically bad comments ? ;)
arrgggggg Laurent
|
Sadly not ;-)
Less than a few lines though..
Regards, Gary
|
In reply to this post by laurent laffont
On 15 February 2011 18:29, laurent laffont <[hidden email]> wrote:
> So the comment I propose mixing what you said with my understanding: > I'm an abstract class which introduce a filter between a drawing request and > the final output, handled by #mapColor: > For each potential pixel operation like: source -> op -> output > it introducing a color mapping stage: source -> op -> mapping -> output > Then #mapColor: can be redefined in subclasses to implement more specific > behavior. For example: > - ShadowDrawingCanvas will replace the rendered color with the color of > shadow (if not transparent). > - AlphaBlendingCanvas will add or intensify alpha of rendered color. > > For an easy to understand example see > #drawPolygon:color:borderWidth:borderColor: > ShadowDrawingCanvas: > see ColorMappingCanvas comment. > AlphaBlendingCanvas: > see ColorMappingCanvas comment. > Sounds good. > Laurent. > On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 14 February 2011 18:45, laurent laffont <[hidden email]> >> 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. >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |