Seeking Web Gadget Display Speed Improvement
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Seeking Web Gadget Display Speed Improvement
I have a number of HTML files, all of which consist only of one table. They are displayed via Web Gadgets on a Panel (tabbed). Although relatively small, the display is slow enough that the User first sees a blank page and then the page builds over 1-2 seconds. It's probably better on a fast Windows 10 machine but if I can I would like to optimise.
Instead of loading the Web Gadgets with HTML files on demand from the hard drive, is it possible to load the files from ram?
Edit: Better Subject Title
Instead of loading the Web Gadgets with HTML files on demand from the hard drive, is it possible to load the files from ram?
Edit: Better Subject Title
Last edited by IdeasVacuum on Thu Jun 18, 2020 2:37 pm, edited 2 times in total.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking display speed
If it's only your own HTML files in a table, that aren't loading anything online, then they should display instantly. Got an example HTML table so we can see?
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking display speed
Hi Barry
They are proprietary. Most are around 3KB, 45 - 50 lines and the largest is only 22KB, 454 lines. The delay is in the fact that they are read from a hard drive - it's well known that small files on large drives take some milliseconds to locate.
Hence the idea of storing them in the exe as binary, but that will only be advantageous if the Web Gadgets can subsequently be populated without having to save anything to the drive.....
They are proprietary. Most are around 3KB, 45 - 50 lines and the largest is only 22KB, 454 lines. The delay is in the fact that they are read from a hard drive - it's well known that small files on large drives take some milliseconds to locate.
Hence the idea of storing them in the exe as binary, but that will only be advantageous if the Web Gadgets can subsequently be populated without having to save anything to the drive.....
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
I have put the content of a whole 4486 byte html file in a DataSection as a single-line string.
However, Restore --> Read --> SetGadgetItemText() takes about the same time as loading a hard drive URL (maybe a tiny tiny bit quicker but not worthwhile).
I recall in the WindowsXP days creating a virtual ram drive and reading files from there, which was instant.
Edit: Just defining the whole content as a string works too, but it still takes about the same time (rather negates the use of a DataSection for strings?)
Edit 2: Tried PokeS() (at App Startup), PeekS() (directly into SetGadgetItemText() at startup), works well, but still no noticeable speed gain
Also, it's no faster on Windows 10 than on Windows 7. So, I think I have to live with it. Still, storing the files as strings in the exe is definitely preferable to distributing them.
However, Restore --> Read --> SetGadgetItemText() takes about the same time as loading a hard drive URL (maybe a tiny tiny bit quicker but not worthwhile).
I recall in the WindowsXP days creating a virtual ram drive and reading files from there, which was instant.
Edit: Just defining the whole content as a string works too, but it still takes about the same time (rather negates the use of a DataSection for strings?)
Edit 2: Tried PokeS() (at App Startup), PeekS() (directly into SetGadgetItemText() at startup), works well, but still no noticeable speed gain
Also, it's no faster on Windows 10 than on Windows 7. So, I think I have to live with it. Still, storing the files as strings in the exe is definitely preferable to distributing them.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking display speed
You can do that (inject a HTML string directly into a WebGadget without hard drive access). I'd be happy to do some tests if you provide me one example HTML table (if not private)? To repay your kind help for my EditorGadget bolding.IdeasVacuum wrote:Hence the idea of storing them in the exe as binary, but that will only be advantageous if the Web Gadgets can subsequently be populated without having to save anything to the drive.....
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
Hi Barry
This is how I have done it, converting each HTML to a single-line string. The difference between streaming a string directly into a Web Gadget and Poking the string is negligible, so this is over-the-top really.
Then the Web Gadgets are each populated like so:
The only limitation is that this can only be done with small files since literal strings have a limit of 8192 chars (not sure how that is determined because char byte size in UTF8 varies).
This is how I have done it, converting each HTML to a single-line string. The difference between streaming a string directly into a Web Gadget and Poking the string is negligible, so this is over-the-top really.
Code: Select all
Global Dim igChars.i(9)
Global *MemChart00 = AllocateMemory(2702) : igChars(00) = 1350
Global *MemChart01 = AllocateMemory(2376) : igChars(01) = 1187
Global *MemChart02 = AllocateMemory(2538) : igChars(02) = 1203
Global *MemChart03 = AllocateMemory(4260) : igChars(03) = 2129
Global *MemChart04 = AllocateMemory(3064) : igChars(04) = 1531
Global *MemChart05 = AllocateMemory(5414) : igChars(05) = 2706
Global *MemChart06 = AllocateMemory(4234) : igChars(06) = 2116
Global *MemChart07 = AllocateMemory(5744) : igChars(07) = 2871
Global *MemChart08 = AllocateMemory(3292) : igChars(08) = 1645
Global *MemChart09 = AllocateMemory(4222) : igChars(09) = 2110
Global sgChart00.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart01.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart02.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart03.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart04.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart05.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart06.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart07.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart08.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
Global sgChart09.s = "<!DOCTYPE html><html><head><meta charset='utf-8'> <meta name='viewport' content='wid~
PokeS(*MemChart00, sgChart00, igChars(00), #PB_UTF8)
PokeS(*MemChart01, sgChart01, igChars(01), #PB_UTF8)
PokeS(*MemChart02, sgChart02, igChars(02), #PB_UTF8)
PokeS(*MemChart03, sgChart03, igChars(03), #PB_UTF8)
PokeS(*MemChart04, sgChart04, igChars(04), #PB_UTF8)
PokeS(*MemChart05, sgChart05, igChars(05), #PB_UTF8)
PokeS(*MemChart06, sgChart06, igChars(06), #PB_UTF8)
PokeS(*MemChart07, sgChart07, igChars(07), #PB_UTF8)
PokeS(*MemChart08, sgChart08, igChars(08), #PB_UTF8)
PokeS(*MemChart09, sgChart09, igChars(09), #PB_UTF8)
Code: Select all
SetGadgetItemText(#WebChart03, #PB_Web_HtmlCode, PeekS(*MemChart03, igChars(03), #PB_UTF8))
SetGadgetItemText(#WebChart04, #PB_Web_HtmlCode, PeekS(*MemChart04, igChars(04), #PB_UTF8))
Last edited by IdeasVacuum on Sat Jun 20, 2020 1:55 am, edited 1 time in total.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking Web Gadget Display Speed Improvement
Looks normal enough, but can you zip and upload a raw HTML table for me to test? I've got no work this morning so lots of free time to play. Even if it's just to say "it's instant here" so you'll know if your PC is the issue, and not the WebGadget.
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
Thanks for the offer Barry but it's already been tested and approved by the Clients.
The issue is effectively the time it takes Windows to render a pre-loaded page. I'm nit picking - the HTML tables are faster (and better looking) than the original List Icon approach and in this case there is no User interactivity.
The issue is effectively the time it takes Windows to render a pre-loaded page. I'm nit picking - the HTML tables are faster (and better looking) than the original List Icon approach and in this case there is no User interactivity.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking Web Gadget Display Speed Improvement
Okay. It's not a Windows redraw issue, maybe? "SendMessage_(GadgetID(#WebGadget),#WM_SETREDRAW,0,0)" to speed it up?
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
... It is a rendering thing, the tiny files take roughly the same time as the larger files. The priority of the App also comes into play.
Edit: The files are preloaded and static.
Edit: The files are preloaded and static.
Last edited by IdeasVacuum on Sat Jun 20, 2020 2:37 am, edited 1 time in total.
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
For anyone interested in loading larger files that hold more than a table:
Code: Select all
DataSection
LargerFile:
IncludeBinary "C:\Users\~\large.html"
EndDataSection
Code: Select all
SetGadgetItemText(#WebLF, #PB_Web_HtmlCode, PeekS(?LargerFile, 21559, #PB_UTF8))
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking Web Gadget Display Speed Improvement
Slightly more convenient way to calculate file length of Included file...
Code: Select all
DataSection
LargerFile:
IncludeBinary "C:\Users\~\large.html"
LargerFileEnd:
EndDataSection
SetGadgetItemText(#WebLF, #PB_Web_HtmlCode, PeekS(?LargerFile, ?LargerFileEnd-?LargerFile, #PB_UTF8))
Last edited by Paul on Sat Jun 20, 2020 3:50 pm, edited 1 time in total.
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
Hi Paul
It is indeed. I did not use that method because, given that I coded the HTML, I already know the file sizes and char counts.
I found this morning that the greatest contribution to rendering speed is to give the App higher than normal priority.....
It is indeed. I did not use that method because, given that I coded the HTML, I already know the file sizes and char counts.
I found this morning that the greatest contribution to rendering speed is to give the App higher than normal priority.....
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
-
- Always Here
- Posts: 6425
- Joined: Fri Oct 23, 2009 2:33 am
- Location: Wales, UK
- Contact:
Re: Seeking Web Gadget Display Speed Improvement
For a couple of additional files I used this method (in the seeking of speed )
However, both files were displayed with garbage at the end, whereas if I hard-code the size, the display is perfect.
Bug or just the consequence of UTF8?
Code: Select all
SetGadgetItemText(#WebLF, #PB_Web_HtmlCode, PeekS(?LargerFile, ?LargeFileEnd-?LargeFile, #PB_UTF8))
Bug or just the consequence of UTF8?
IdeasVacuum
If it sounds simple, you have not grasped the complexity.
If it sounds simple, you have not grasped the complexity.
Re: Seeking Web Gadget Display Speed Improvement
Maybe change the flag to this?IdeasVacuum wrote:For a couple of additional files I used this method (in the seeking of speed )
However, both files were displayed with garbage at the end, whereas if I hard-code the size, the display is perfect.
Bug or just the consequence of UTF8?
Code: Select all
#PB_UTF8|#PB_ByteLength
SetGadgetItemText(#WebLF, #PB_Web_HtmlCode, PeekS(?LargerFile, ?LargerFileEnd-?LargerFile, #PB_UTF8|#PB_ByteLength))