[Pharo-project] [COTDC] 11 - ColorMappingCanvas
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. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent
On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> 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 <siguctua@gmail.com> wrote:
On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> 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
-- Best regards, Igor Stasenko AKA sig.
On Feb 14, 2011, at 8:51 50PM, laurent laffont wrote:
On Mon, Feb 14, 2011 at 7:57 PM, Igor Stasenko <siguctua@gmail.com> wrote: On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> 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.
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 <siguctua@gmail.com> wrote:
On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> 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 15 February 2011 18:29, laurent laffont <laurent.laffont@gmail.com> 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 <siguctua@gmail.com> wrote:
On 14 February 2011 18:45, laurent laffont <laurent.laffont@gmail.com> 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.
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 ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Monday, February 14, 2011 5:45 PM Subject: [Pharo-project] [COTDC] 11 - ColorMappingCanvas 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. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent
On Tue, Feb 15, 2011 at 6:09 PM, Gary Chambers <gazzaguru2@btinternet.com>wrote:
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)!
oh.... do you have a script to detect automatically bad comments ? ;)
Try on a SystemBrowser, for instance... quite cryptic!
arrgggggg Laurent
Regards, Gary
----- Original Message ----- *From:* laurent laffont <laurent.laffont@gmail.com> *To:* An open mailing list to discuss any topics related to an open-sourceSmalltalk <pharo-project@lists.gforge.inria.fr> *Sent:* Monday, February 14, 2011 5:45 PM *Subject:* [Pharo-project] [COTDC] 11 - ColorMappingCanvas
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. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest
Laurent
Sadly not ;-) Less than a few lines though.. Regards, Gary ----- Original Message ----- From: laurent laffont To: Pharo-project@lists.gforge.inria.fr Sent: Tuesday, February 15, 2011 5:31 PM Subject: Re: [Pharo-project] [COTDC] 11 - ColorMappingCanvas On Tue, Feb 15, 2011 at 6:09 PM, Gary Chambers <gazzaguru2@btinternet.com> wrote: 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)! oh.... do you have a script to detect automatically bad comments ? ;) Try on a SystemBrowser, for instance... quite cryptic! arrgggggg Laurent Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Monday, February 14, 2011 5:45 PM Subject: [Pharo-project] [COTDC] 11 - ColorMappingCanvas 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. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent
participants (4)
-
Gary Chambers -
Henrik Johansen -
Igor Stasenko -
laurent laffont