|  | | | | |
Slow Form Navigation and Record Scrolling
| | |  | Sample Newsgroup Questions |
| | Form Extremely slow moving to next record
OLE Frustration - slow and cumbersome
Viewing Images on Form too slow.
Slow image control
Very Slow Database
Access forms refresh very slow
|
|
|
| |
|
|
Compared to simple data-types (like text and numbers) image data is both large and complex. Uncompressed images (such as bmp format) are particularly large, needing significant time to read from disk (whether stored in the file-system or inside the database). Compressed images, especially JPEG, are much smaller, but complex, requiring significant CPU effort to 'decode' into a displayable image.
When you display an image on a form using the Access Image Control or an OLE Frame, images are loaded and decoded synchronously, i.e. the form freezes until the image has been read and decoded. This can take a significant time, and is particularly noticeable when scrolling through records. The effect can range from 'frustrating' to 'unusable'.
The best solution is to use an image control which decodes 'asynchronously' (in the background), then you can use fast and compact compressed images without the decoding penalty (Read More), but if you're stuck with the built-in imaging capabilities of Access there are a few steps you can take to reduce the performance penalty.
1) Only Display the image 'On-Demand'.
For example, provide a button on the main form to open/view the image, or display the image on a separate tab (and only load the image when the user switches to that tab). This completely mitigates the overhead, but also removes much of the benefit of having the image in the first place, i.e. the instant recognition that an image provides of a person, place, product etc.
2) Reduce the image resolution.
Your source images may have a much higher resolution than required for on-screen display (e.g. typical digital camera images). If this is the case, not only is there unnecessary disk and decoding overhead, but also the display quality of the resulting image will be lower than an image that has been resampled for the specific resolution at which it will be viewed. By reducing the resolution suitable for display on-screen at 1:1 both performance and display quality will be improved, however this will require additional components and potentially complex coding. For high-res output (e.g. printing) you may also need to retain a high-res or original copy of the image.
3) Display a low-res thumbnail linked to a high-res image.
This is a compromise between 1) and 2). The main form display a low-resolution thumbnail that can be clicked to open a higher resolution 'detail' image. The low-res image reduces the reading and decoding overhead on the main form, and the user can display a more detailed image on-demand. Like 2, however, this will require additional components, coding or user-interaction to prepare the thumbnail images.
4) Third-party Components.
The DBPix image control is designed for optimal image-handling in Access, and offers background image decoding for super-fast record scrolling, plus resampling/thumbnailing capabilities to optimize resolution and display quality, and is easy to use for both developers and end-users. Read More.
Related Articles
Run-Time error '2114' Microsoft Access doesn't support the format of the file
Preventing the "Scroll-too-Quick" Crash
Hide the Loading Image dialog ("Importing" message)
Imaging for Access that's Easy, Efficient & Fast
| | NO OLE Bloat | | NO App Dependencies | | NO Complex Coding | | NO Performance Penalty |
| |  | Read More
|
|
Microsoft and the Office logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries. |
| |
|
|
Home
Tutorials