W+ reproducibly locks up when (un)zooming a picture

[ttcoder]

Occurs easily if the picture is much more large/tall than the W+ window, so resize your W+ window down before doing the below:

Steps:

• click e.g. ​this link
• left-click (zoom)
• left-click (unzoom)

W+ should be locked up; if not, try a long series of fast clicks, and try to resize down the window.

Not a highly prominent problem, but posting in case it helps diagnose some other bug(s) that are less easy to reproduce

[ttcoder]

The BWindow is possibly blocked waiting for the offscreen bitmap lock

[ttcoder]

ps -as mentions 3 active semaphores (?):

Team                                                  Id #Threads  Gid  Uid 
/boot/system/apps/WebPositive                       5821        8    0    0 

Thread                                   Id    State Prio    UTime    KTime
WebPositive                            5821     wait   15      871      240 WebPositive(291808)
pthread func                           5826     wait   10        4        1 
w>Downloads                            5828     wait   15       11       13 
w>Settings                             5830     wait   15       26       25 
w>WebPositive: Save                    5834     wait   15       31       28 
timer thread                           5836     wait   20       16       14 timer thread control(291836)
w>command_center_large.png - We        5838     wait   15      202       78 offscreen bitmap(292660)
team 5821 debug task                   6333     wait   10        0       36 

FWIW

[ttcoder]

Can no longer lock-up W+ in hrev49814 with that test case and a couple others. Been browsing for an hour or so and only experienced one crash (well known ticket IIRC) and a presumed lock-up, so there's the possibility that "lock-up" tickets are improved or fixed. There's also the youtube regression (no more playback: black video, and garbled audio) but pulkomandy and jua probably know about it already. Congrats on all involved for the improvements :-)

Edit: forgot to mention the memory leak (which I thought was just) associated with the HTML5/youtube regression: it seems that it is not specific to video rendering, because even if just browsing web pages there is an app_server memory leak, which is not returned to system after quitting Web+; maybe the recent app_server improvements allocate extra memory ? I'll collect more data and create a new ticket if no one beats me to it

[pulkomandy]

Sounds like some of your problems deserve separate tickets :)

• Regarding the "leak": I have noticed high memory use in app_server, I don't know if there is an actual leak or just more memory used (we do a lot of things on app_server side that used to be on the application side before)
• Regarding the video problems: it is probably because of ffmpeg update. It is working fine for video here, but I have no soundcard driver so I don't know about sound. On jua's laptop we get working video, and broken sound. We can revert to ffmpeg 0.11 (or some version that still works in between) until the problem is identified and fixed; binary searching ffmpeg versions to see when the problem appeared would be useful.