[interfacekit] Re: Course of action for BScrollBar implementation

> 
> Marc Flerackers and I have been conversing about what way to go for 
> BScrollBar would be best - server-based, client-based, or some 
> compromise 
> between the two. For those uninitiated, R5's app_server handles all 
> input and 
> drawing for scrollbars and everything else AFAIK is handled by client
> -side 
> class code.
> 
> The advantage of the server-based method is that if an application 
> isn't 
> super responsive, you scroll it without lag and then wait for the app 
> to 
> catch up. The down side of this, though, is that developers cannot 
> change the 
> look or input handling of scrollbars.
>
> The client-based method would be just the opposite of the server-
> based method 
> - the ability to modify input handling and looks, but if the app is a 
> problem, scroll speed is limited by the application.
>
> It might also be possible to do some combination of the two which I 
> haven't 
> thought of. Being any of these is possible, what are your thoughts, 
> guys?

Actually I think the server-side scrolling is an anachronism. Even on 
my 240 MHz PPC Box I can implement applications so that the GUI remains 
responsive. It is virtually impossible on a modern machine to make a 
window draw that much, that scrolling becomes sluggish. And if you 
manage to get you window looper unresponsive, then it's not because of 
drawing and you should rather rethink your design -- e.g. spawn a 
thread that does the time-consuming work and draw the scroll bar 
immediately, but the contents when the data are ready.

I vote for `drop the server-side scrolling'.

CU, Ingo

Other related posts: