Re: Achieving very smooth scrolling of large data sets?

From: John Doe (spammeallyoucan_at_hotmail.com)
Date: 06/25/04 

Date: 25 Jun 2004 09:37:59 -0700

Roedy Green <look-on@mindprod.com.invalid> wrote in message news:

> You could do some preemptive caching on a low priority thread, loading
> your cache with look ahead in both directions when you have nothing
> better to do, and pruning your cache.

That's definitely a possibility--probably one of the easier ones to
implement. However when the database is stored on a network server,
this increases network load substantially, especially if the database
is accessed by several client applications. In such a case, preventing
unneeded lookups would be a bit cleaner situation.

I'm OK with things taking a bit after releasing the mouse button or
PgUp/PgDn key, the 0.3 seconds is perfectly acceptible then (showing
an hourglass cursor for that bit of time is not going to offend many
people).

> Another thought is you might want a custom layout manager that uses
> arithmetic to do the mapping from a co-ordinate to a corresponding
> component rather than doing an iterative inside test on each component
> if mouse interaction is slow too.

Below is what I perceived as the meaning of what you said above. Are
you saying to exploit the relative low sensitivity of scrolling by
scrollbar (a screen rarely being more than 1024 pixels high)?

-----------------------
- For instance the screen fits R records at any time, and
- the scrollbar is P pixels high, then we need to cache at
- most P blocks of R records to smoothly scroll through
- the entire database by mouse, regardless of the size of
- the database.
------------------------

That could in fact be an interesting way to go about it- most
computers nowadays will be able to handle, say, holding 60000 records
in RAM (60000 being 60 records per screen*the hight of the scrollbar
in pixels)

However, resizing the window would require repopulating the cache,
unless the added lack of precision is acceptible (then again if we
want precision,
we shouldn't be using scrollbars).

[Reality check: If we display text, it is difficult showing more than
256 chars horizontally on a screen, 16 mb of RAM should do the trick
(plus data structure overhead, of course. But unless we want to do
fancy stuff such as displaying full motion video streams in our table
while scrolling, we should be all right).]

I guess 60000 records can be considered 'modest' memory requirements,
however it can still be quite a load on the network. Even for a
gazillion record database, I wouldn't want to load many megabytes of
data before being able to scroll- that's where the "showing only 1
record while scrolling" would come in.

But then again, maybe I completely misunderstood what you meant.

This still woudn't fully solve the scrolling by PgUp/PgDn but I
suppose it is possible to consult the keyboard buffer and prevent a
number of lookups. In addition, navigation by PgUp/PgDn is a bit more
predictable than mouse movements- preemptive caching on a low priority
thread will work wonderfully there.

Best Regards,

John

Quantcast