From: joakim v. <jo...@ve...> - 2004-04-12 00:55:48
|
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 |