>
>  The paint times for 7.2 seem inconsistent with your previous tests...


Correct. That run was a bit of an outlier. The 7.2 runs are mostly in line 
with 7.3 with respect to paint.

Here's what I get for mouse callback stats with this code 
<http://pasterack.org/pastes/88406> when I use different thresholds for 
delta:

Version Min Max Mean StdDev 
7.2; delta < 2 0 22 3.398 3.968 
7.3; delta < 2 0 210 4.795 18.214 
7.2; delta < 20 0 22 2.332 3.64 
7.3; delta < 20 0 206 9.728 19.46 
7.2; delta < 200 0 106 2.961 7.802 
7.3; delta < 200 0 239 29.579 34.369 

With a smaller delta, more overlays are able to be shown in 7.3, but it is 
still noticeably laggy compared to 7.2 (looks like about a third of the 
frequency of updates). I suppose I can try this approach with my plot code 
if I upgrade to 7.3, but it's kind of upsetting.

Evan

On Friday, June 7, 2019 at 2:07:26 PM UTC-10, Alex Harsanyi wrote:
>
> The paint times for 7.2 seem inconsistent with your previous tests...
>
> In any case, it seems mouse event handling takes longer in 7.3 based your 
> results.  What happens if you update the callback to discard any mouse 
> events older than, say 50 milliseconds?
>
> Alex.
>
> On Friday, June 7, 2019 at 7:27:32 PM UTC+8, evdubs wrote:
>>
>> I changed the Linux line of code to:
>>
>> [time-stamp (current-milliseconds)]
>>
>> Is there a reason why you did not want to do that?
>>
>> Any way, when I do that, here are the results I get:
>>
>> $ ~/racket-7.2/bin/racket chart-lag-test.rkt
>> Mouse
>> Min: 0.132080078125
>> Max: 23.10107421875
>> Mean: 3.257062241367008
>> StdDev: 4.589805152078677
>>
>> Paint
>> Min: 0.178955078125
>> Max: 102.94091796875
>> Mean: 28.86041259765625
>> StdDev: 42.84071031974706
>>
>> $ ~/racket-7.3.0.4/bin/racket chart-lag-test.rkt
>> Mouse
>> Min: 0.126953125
>> Max: 202.34912109375
>> Mean: 25.70277455891149
>> StdDev: 38.4063903237421
>>
>> Paint
>> Min: 0.175048828125
>> Max: 21.754150390625
>> Mean: 7.548767089843749
>> StdDev: 8.728339324923978
>>
>> If this modification is okay, I guess this is getting somewhere?
>>
>> Evan
>>
>> On Wednesday, June 5, 2019 at 5:43:40 PM UTC-10, Alex Harsanyi wrote:
>>>
>>>
>>>
>>> On Wednesday, June 5, 2019 at 9:23:26 PM UTC+8, Alex Harsanyi wrote:
>>>>
>>>>
>>>>
>>>> On Wednesday, June 5, 2019 at 8:51:48 PM UTC+8, evdubs wrote:
>>>>>
>>>>> I ran the program with your modifications, but counter to the 
>>>>> documentation 
>>>>> <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>,
>>>>>  
>>>>> the values I get from get-time-stamp don't seem at all similar to 
>>>>> current-milliseconds or current-inexact-milliseconds. I ended up defining 
>>>>> delta as follows (with 1559695139340 being a guess):
>>>>>
>>>>> (define delta (- (current-inexact-milliseconds) 1559695139340 (send 
>>>>> event get-time-stamp)))
>>>>>
>>>>>
>>>> On my machine, `get-time-stamp` always returns 0 -- this indicates that 
>>>> the event% object itself is copied somewhere along the way but the 
>>>> timestamp is not copied, The 1559695139340 is just the unix timestamp from 
>>>> when you ran the code first time.  I don't think the mouse test is 
>>>> relevant 
>>>> as is...  unfortunately I don't have any more suggestions for now...
>>>>
>>>
>>> It looks like the `get-time-stamp` returns a value that is not what the 
>>> documentation specifies and it is also platform specific, I created an 
>>> issue with the relevant details here: 
>>> https://github.com/racket/gui/issues/132
>>>
>>> For now, I cannot think of a way to determine how old a mouse event is 
>>> when the callback is invoked.
>>>  
>>>
>>>>
>>>> Alex.
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/fc444671-73b4-4d61-b9ce-8c37a4812a26%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to