On Oct 11, 2007, at 6:25 PM, Mattias Gaertner wrote:
On Thu, 11 Oct 2007 08:53:35 -0700
Peter Gannon <[EMAIL PROTECTED]> wrote:
[snip]
Yes, hopefully some solution will arise to allow direct drawing to
the screen outside of paint events. Most programs do some kind of
direct painting at some stage, so when porting, those areas would
need to be rewritten specifically to overcome this limitation on the
Mac/Carbon/Lazarus.
Most programs? Can you give some examples?
Hi Mattias
1- On PC Delphi, screen flashing on heavy updates can occur. What I
think is probably a common workaround (though perhaps I'm the only
Delphi programmer who ever did this)--
Rather than calling Invalidate and letting the OnPaint draw
everything, in some cases you just call OnPaint, which 'draws over'
the stuff already there, giving a quick clean visible change of only
the parts which have changed. The parts of the image that are the
same do not flicker, because you are just 'drawing over' what was
already onscreen.
This might not be a 'kosher' trick (though I see nothing wrong with
it). But if this trick works on PC Lazarus (which I've verified), but
it doesn't work on Mac Lazarus, then there might be a lot of code
from the PC that would need to be changed to work on the Mac, which
would somewhat defeat the beauty of Lazarus as a cross-platform
solution.
Even with such necessary adjustments, Lazarus would still beat heck
out of completely rewriting an app for Mac. But IMO the fewer changes
the better (grin).
2. I use direct drawing a lot in a MIDI Piano Roll editor on PC. I
draw the 'marching ants' XOR rectangle if the user click-drags on
open space to select a group of notes.
If a group of notes have been selected and the user click-drags the
beginning of a selected note bar, XOR 'ghost images' of the selected
notes follow the mouse left-right until the mouse is released, at
which time invalidate is called and the entire complicated content is
redrawn with new note positions.
Similar XOR 'ghost images' follow the mouse vertically for pitch
changes, if the user clicks on the middle of one of the note-bars.
And XOR 'ghost images' change the duration of selected notes if the
user clicks on the tail of one of the selected note-bars.
3. LED Audio VU Meters-- These things look best when they update
pretty frequently. It is typically done by having rectangular bitmaps
of the VU Meter 'All Off', and another bitmap of the VU Meter 'All
On'. Depending on the audio instantaneous level, you blit a
percentage of the 'All On' image to the bottom of the VU Meter and
then blit a percentage of the 'All Off' image to the top of the VU
Meter.
4. On a Music Notation window-- All the Staves, barlines, and notes
are drawn with the OnPaint event. And then during playback the task
is to draw individual notes in Red when the sequencer starts each
note, and then redraw each note in Black when the sequencer stops
each note. So you want to (quickly) only update little pieces of the
notation with spots of Red or Black.
5. Similarly on an animated music keyboard, you want to 'light up'
the keys as they play, updating little pieces of the entire keyboard
bitmap.
Those are music program examples, because we write music programs,
but there are probably plenty of other uses in other types of
applications. If writing a PhotoShop like program, or a CAD program,
a lot of mouse-tracking would probably be easier with some kind of
direct-draw mechanism.
It isn't like the cat cannot be skinned by changing drawing strategy
on Carbon Lazarus, but perhaps optimizations for a Carbon version of
a program would perform worse on a PC, causing code forking. Code
forking would be nice to avoid (as much as possible). For instance,
rewriting the code a 'carbon laz' way might make that code flash a
lot on the PC. Just a possibility.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
