I have tried logging everything possible to find where a few seconds of time has vanished to, with no luck.
I have a SHEET window that has some popupmenus and textfields on it.
The top Popup menu has two choices… and depending on which is chosen causes
label “A”, and texdtfield “A” to be hidden and label “B” with Popup “B” to become visible (or vice versa)
Not rocket science…
When I select from the top popup, the label there changes immediately… but it may be 3 to 5 seconds before the labels/input fields swap out
Any logging I put, indicates that like 0.00001 seconds elapse, which is not what I see visually
the CHANGE event for the top popup (where I select the mode) is… the “DEBUG” logs the event and takes no time itself (to speak of)
Sub Change() Handles Change
debug "A"
setStyle me.ListIndex+1
debug "B"
End Sub
setstyle is
Private Sub setStyle(newValue as integer)
debug "SET STYLE "+str(newValue)
Select Case newVALUE
Case 1 // User Caption
lbl(1).Visible=true
inpLABEL.Visible=true
lbl(2).Visible=false
puICON.Visible=false
Case 2 // User Icon
lbl(1).Visible=False
inpLABEL.Visible=False
lbl(2).Visible=true
puICON.Visible=True
End Select
Items(current_row).Style=newValue
updateLISTBOX current_row // rebuilds listbox which has TWO items in it
debug "SET STYLE : Exit"
End Sub
Like I said, when I click the popup, its 3 to 5 seconds (with rainbox pizza) before the screen returns
its not that… I’ve used (and profiled) that method for years… plus the elapsed time shown in the log from the first to last event is 1/60 of a second… but from my visual point of view that is taking 3-5 seconds.
the delay “feels” like it is between the time I click a selection in the popup to the time the “change” event actually fires… therefore the logs show a short time period… since the actually process is short… it just twiddled its thumbs before it started…
Ok…not sure why (yet)… but the line
updateLISTBOX current_row
does an invalidate on the row… which is fine
but then 2 seconds later it calls cellbackground paint again for no good reason that I can determine
as I noted… it rebuids the listbox from scratch… which it doesn’t really need to do… but there are onlly two items
I did change the code to only do a full rebuild if there were multiple changes… and that did not help
I also discovered the changing the mode from “A” to “B” causes the delay, but from “B” to “A” does not
and A->B causes it to do a cellbackgroundPaint event 2-3 seconds after it should have been finished…
but so far I cannot find what is triggering that to happen.
FYI. “A” draws only text in the cell… “B” mode draws only an Icon…
but the logs show it still goes thru updateListbox is < 1/60th second
I think its whatever is causing it to call BackgroundPaint a 2nd time (and no I have no invalidate that are not accounted for)
Dim i As Integer
Dim last As Integer
debug "update"
if indx_row<0 or force then
lb_seg.DeleteAllRows
For i=0 To Items.Ubound
lb_seg.AddRow ""
last=lb_seg.LastIndex
lb_seg.rowtag(last)=i
Next i
else
debug "one"
lb_SEG.InvalidateCell(indx_row,-1)
end if
If indx_row<>current_row Then setROW indx_row,0
update_buttons
debug "update exit"
but It cannot be this… because the time elapsed between the enter and exit messages <1/60th of a second
The issue has become why does it call CellbackgroundPaint twice,…
FYI… when it calls this it only does the Invalidate line…
and next will be what is in Cellbackground paint… that IS more complex… but again… <1/60th of a second
This is why I put those DEBUG statements all over the place… in order to find a piece of code that took too long,
what this issue seems to be… it the delay is AFTER the “B” message above … after it should be finished … something else is happening… almost like it consumed a huge amount of memory, and is cleaning up… hmmmm… let me check that
well during that time… CPU jumps to 100% and Memory goes from 97meg to 650meg!.. then it drops to 2% and 97meg
it has to do with the fact an IMAGE is being drawn … and it has to find it, scale it, and display it…
let me look into caching images as they are loaded… cache once use many
[quote=412702:@Dave S]it has to do with the fact an IMAGE is being drawn … and it has to find it, scale it, and display it…
let me look into caching images as they are loaded… cache once use many[/quote]
Scaling has become much slower in recent times.
A suggestion that may help, to further your caching idea:
Preload the images, yes
But as you addrows, set the rowtag to be the scaled image.
If a cell needs to be redrawn, get it from the rowtag not disc?
Found it… couldn’t understand why the memory and CPU were going thru the room for something that should have been so easy. Turns out the routine that manipulated the graphic was supposed to return a 60x60 icon… but somehow the constant ended up as 6000 x 6000 … or 10,000 times bigger… it works perfectly now
[quote=412727:@Dave S]Found it… couldn’t understand why the memory and CPU were going thru the room for something that should have been so easy. Turns out the routine that manipulated the graphic was supposed to return a 60x60 icon… but somehow the constant ended up as 6000 x 6000 … or 10,000 times bigger… it works perfectly now
“Somehow”… yeah I’m still trying to figure out how a Constant ended up with 2 extra zeros… but I have had stranger things happen… Sometimes I position the cursor in the IDE , start typing, and the cursor is no where near where it should have been
Are you by any chance using a recent-vintage MBP? They are notorious for random cursor jumping. I like the machine a lot, but I waste huge amounts of time backspacing and retyping stuff that ended up elsewhere from where I was typing, and constant vigilance is required.
No… currently on a 2017 27" iMac … it doesn’t happen often… but it does happen… especially when I click in the Right side pane to change a method name or property… it jumps back into the code pane…
I believe these are Xojo bugs, but I cannot find out how to trigger them reliably.
Sometimes when copying code in a method part of a loop gets folded in, but is somehow only reduced to one line. If you then try to undo your changes, the result is a complete mess and you have to reconstruct the code from memory.
What has become better with the latest release is that the code editor does not select a portion of code I dod not want to, forcing me to scroll back to the original place again. I have not seen this with r3, but it was still present in some of the prereleases.