Forum Archive

With my scrolling VirtualView, I wanted to create a stress test for it. I didn't want to insert the stress test code into my class. So I created the Stress Class below. After my VirtualView is presented from my main, I then just create an instance if the Stress class passing it a reference to the VirtualView Class.
So all it does is scroll the view on page at a time. When it reaches the end of the scrollable content, it starts from the top of the list again.
Maybe some will think I am manic :) but I want a test like this. I will run when sleeping when my iPad is charging.

What I don't know, if I am creating some unstable conditions by calling the code like this.

I have only run with the Stress object for 15mins or so. The functionality all works fine. But I have had the editor crash a few times when after running this. I am not crashing at runtime.

I understand, this could be something with 1.6 or I could be abusing the use of ui.delay()

Any thoughts appreciated.

class Stress(object):
    # an auto scroller for VirtualView class
    # to stress test it. 
    def __init__(self, obj, delay = .1):
        import console, time 

        # trying for saftey
        ui.cancel_delays()

        # no sleeping...
        console.set_idle_timer_disabled(True)

        self.obj = obj
        self.delay = delay
        # record the start time
        self.start = time.time()
        ui.delay(self.auto_scroll, 2)


    def auto_scroll(self):
        # the scrollview
        sv = self.obj.sv

        # current offset of the scrollview
        v_offset = sv.content_offset[1]
        # calc new_offset, to be + one page 
        new_offset = v_offset + sv.height

        # wrap around if we reach the bottom if the list
        if new_offset > sv.content_size[1]:
            new_offset = 0

        sv.content_offset = (0, new_offset )

        ui.cancel_delays()
        ui.delay(self.auto_scroll, self.delay)

    # __del__ is not being called...
    # moved the running duration code into the
    # VirtualView object.
    #def __del__():
        #ui.cancel_delays() 
        #print time.time() - self.time()

Oh, I just put a call to ui.cancel_delays() Into the will_close of the VirtualView class. I just seen some strange behaviour that made me think I need to do that.

a delay of 0.1 seems pretty short to me! at least randomly insert a larger delay. if your virtualview code hasnt finished, then things might be getting behind ... that works differently than touch events i think, if main thread is busy, i think the touch event is delayed (not 100% sure sbout that). you might want @on_main_thread for the bits that update the scroll position.

oh i misread your problem... check on_screen in the start of autoscroll, and if not onscreen, then return. remember will_close is called on the main thread, while autoscroll is a delayed call running in its own thread, so there is a chance willclose gets called while you are in autoscroll, in which case your cancel all delays wont work, and the method will continue to run.

@JonB, there really is not a problem as such. It's really about understanding how stable all this is and if the way I use it, makes the environment unstable or not. Does not make sense to stress test something with flawed code.
I dont need to worry about if onscreen or not, because the view containing the scroll view is presented before I create the Stress class, so ip for sure its on screen.
But it seems one problem I did have was that when I exited the app, I was not calling ui.cancel_delays. Meaning ui.delay code can still be trying to execute.
The VirtualView class has a clear exit point, 'will_close'. So I call ui.cancel_delays there.
I would prefer that the Stress class del method was called on the program exit so I could clean up without involving the VirtualView class. But it does not.

I take your point about the short time for delay. But who knows how long it will take to complete a cycle (we don't want it to slow) . So I will just try some signalling. True when executing the code ( if executing, bug out) , then set to False when finished so it does not get reenterent. I think that should sovle that problem in a reasonable way.

Another misunderstanding by me, I think. I changed the class as below.it appears it will never be reenterent. Lowest time for delay, also delayed in the building of my cells. You can see I put a print statement in the code if we tried to re enter the code and it was busy. I could not make it happen. So I am guessing ui.delay is not just threading, but threading with a queue.
Really, I am not sure. But it looks that way.

class Stress(object):
    # an auto scroller for VirtualView class
    # to stress test it. 
    def __init__(self, obj, delay = .1):
        import console, time 

        # trying for saftey
        ui.cancel_delays()

        # no sleeping...
        console.set_idle_timer_disabled(True)

        self.obj = obj
        self.delay = delay
        self.busy = False
        # record the start time
        self.start = time.time()
        ui.delay(self.auto_scroll, 2)


    def auto_scroll(self):
        if self.busy:
            print 'i was busy'
            ui.cancel_delays()
            ui.delay(self.auto_scroll, self.delay)
            return 

        self.busy = True

        # the scrollview
        sv = self.obj.sv

        # current offset of the scrollview
        v_offset = sv.content_offset[1]
        # calc new_offset, to be + one page 
        new_offset = v_offset + sv.height

        # wrap around if we reach the bottom if the list
        if new_offset > sv.content_size[1]:
            new_offset = 0

        sv.content_offset = (0, new_offset )

        ui.cancel_delays()
        ui.delay(self.auto_scroll, self.delay)
        self.busy = False

    # __del__ is not being called...
    # moved the running duration code into the
    # VirtualView object.
    #def __del__():
        #ui.cancel_delays() 
        #print time.time() - self.time()

no, it wont ever appear reentrant because you call the delay at the end of the function. if you started two delays at slightly different times, i think it would behave differently. but note that you need a way for this to STOP what it is doing! a flag or checking onscreen would work. cancel delays will work sometimes, but is not guaranteed.

@JonB . Thanks.
I ran this last night on my Virtual View for 7 hours. It created 4.8 million cells scrolling. Each cell contained 2 labels populated with data from faker, a image with a random built in image loaded, and a button with a background picture.
Everything still stable after I stopped it.
So that's a reasonable stress test

@JonB , I can be such a fool sometimes. You gave me the answer, I was just not listening correctly .
Now when I enter the auto_scroll method, I am checking to see if the view is onscreen. It it's not, I do del self and return. Then my del method is called, where I can clean up properly. It also now removes any dependence from the class that it is stressing. Meaning it could be used to test a number of ui interfaces that for what ever use a lot of memory. Also can expand it a little to collect some stats along the way.

But thanks again. Good to have that done before the F1 today :)