jazzplusplus-devel

[jazzplusplus-devel] some notes about flickering background in jazzpp

[joakim v. <jo...@ve...>]

Hello,

Here are some things I figured out about the background flicker that 
might or might not be news to you:

- Double buffering is easily achieved by the method Patrick suggested. 
(drawing to a temp dc and blitting)

- Sadly, this doesnt really help!

- Nowadays there is a "background erase event", that you can catch.
The default implementation of the event catcher should fill the 
background with grey.

Jazzpp fills the background with black however. I dont know why. This is 
why the flicker is so annoying,
at least for me.

- When I implement a dummy "bg erase" handler that does nothing, I get 
grey background erase,
which is much less annoying.

- implementing the "erase" handler and also implementing "double buffering"
seems achieve rock-solid redraw, but my implementation currently has 
other problems:
a) you need a background bitmap to draw in, and I havent figured out how 
to know the right size for it yet
b) events doesnt get drawn for some reason

Anyway, I think I'm on the right track, and we can at some future time 
have beautiful screen
updates like Rosegarden :-P


Cheers,
/Joakim

Re: [jazzplusplus-devel] some notes about flickering background in jazzpp

[Dave F. <dav...@co...>]

On Sunday 11 April 2004 02:42 am, joakim verona wrote:
> - implementing the "erase" handler and also implementing "double buffering"
> seems achieve rock-solid redraw, but my implementation currently has
> other problems:
> a) you need a background bitmap to draw in, and I havent figured out how
> to know the right size for it yet
> b) events doesnt get drawn for some reason

Assuming the space needed is larger than the window ever gets, can you just 
draw the whole thing in your memory dc and then copy only the part that you 
need for the window when you need it?  Also, how does this affect selection?  
I noticed some serious bugs in selection, and haven't managed to track them 
down (it was hitting these bugs at the end of my last jazz timeslice that 
stopped me from finishing the selection interface in the Project class).

> Anyway, I think I'm on the right track, and we can at some future time
> have beautiful screen
> updates like Rosegarden :-P

Heh, you mean beautiful the RoseGarden's are beautiful, but you expect them to 
actually work, too, right?  ;)  (I spend more time swearing than composing 
when I use RoseGarden...)

Dave

-- 
Visit my website!
http://www.davefancella.com/?event=em

"What is wanted is not the will to believe, but the will to find out, which is
the exact opposite."
-- Bertrand Russell, _Sceptical_Essays_, 1928

Re: [jazzplusplus-devel] some notes about flickering background in jazzpp

[joakim v. <jo...@ve...>]

Dave Fancella wrote:

>
>Assuming the space needed is larger than the window ever gets, can you just 
>draw the whole thing in your memory dc and then copy only the part that you 
>need for the window when you need it?  
>

Well thats basically the idea of double buffering combined with clipping.
Its not rocket science, but theres a lot of little details, like the 
translation
of coordinate spaces between scrolled and unscrolled areas. (sounds way 
harder than it is)

>Also, how does this affect selection?  
>I noticed some serious bugs in selection, and haven't managed to track them 
>down (it was hitting these bugs at the end of my last jazz timeslice that 
>stopped me from finishing the selection interface in the Project class).
>  
>
Which selection bugs are you talking about?

These are the ones I know about:

- The selection area doesnt follow the scroll area.
I believe this works at the moment.

- The selection doesnt draw very well.
This is because jazz sometimes uses a very lame screen update method.
It creates client dc:s in event handlers, and draws into them.

This is done with the selection and with the piano keys for instance.

This means screen updates are sometimes transient in jazz.

Its easier to explain how it *should* work:

- when you select a couple of events, these event should be marked as 
selected in
the "model". Then the gui should be redrawn with the selection state 
being taken
in consideration.

The effect would be more recognizeable as a standard ui paradigm as well.
A "rubber band" could be used for selection, and "selection state" could 
be indicated
with the events being drawn with thick borders or something.

So that would mean that as long as the model is updated properly, and 
the view drawing code is
correct, the views always represent the model properly. This maybe 
doesnt sound like much,
but currently it is impossible for the jazz gui to achieve this since it 
makes screen updates in
event handlers that are later forgotten.

Cheers,
/Joakim