[Web+] System freeze during file upload on fontdrop.info

[bitigchi]

Steps:

• Be ready for a system freeze
• Grab a font file
• Visit fontdrop.info
• Upload the font file

Expected:

• Font contents should be displayed

Results:

• System freeze, mouse does not move

[diver]

System freezes are usually app_server or kernel (drivers) related.

[humdinger]

More often than not, the Web+ window just closes after some time. This is what I found in the syslog:

KERN: 953: DEBUGGER: Could not create BWindow's receive port, used for interacting with the app_server!
KERN: _user_debugger(): Failed to install debugger. Message is: `Could not create BWindow's receive port, used for interacting with the app_server!'
KERN: thread_hit_debug_event(): Failed to create debug port: No more ports available

I did have one system freeze, OTOH, fonts with a small file size do work with the site.

[pulkomandy]

Sounds like running out of message ports, crashing, and then failing to start debugger.

[X512]

A lot of "offscreen bitmap" and "w<app_server" ports in WebPositive.

[X512]

It is likely caused by creating a lot of BBitmap's that accept views. Such bitmaps create offscreen window and 2 threads and 3 ports for each bitmap.

[waddlesplash]

It would be much better if we could rework the Web+ drawing code to not create so many BWindowed BBitmaps, but only have one (i.e. for the current drawing surface.)

[X512]

If I understand correctly, current API don't allow to attach/detach offscreen window to existing bitmap. Drawing to bitmap will require to copy bitmap contents to some global bitmap with offscreen window and copy back when drawing is finished.

[pulkomandy]

Yes, the use of offscreen bitmaps is indeed causing running out of ports.

We can't change this in WebKit, it is designed to draw to offscreen buffers and then blit them to apply various compositing operations.

Some of the need for this was removed with the recent addition of new drawing modes, but I don't remember if this was integrated in beta2 (I thinik not?). In that case, maybe we should backport the new drawing modes there and update webkit first.

I think we should still do something to improve the way debug_server handles this. If it fails to attach debugger to the app_server thread, it is not good user experience to freeze everything. At the minimum it should echo something to /dev/console to signal the problem using on-screen debug console.

And we can also consider increasing the limit on number of ports, currently it is at 4096 but we can make it higher.

[X512]

Replying to pulkomandy:

We can't change this in WebKit, it is designed to draw to offscreen buffers and then blit them to apply various compositing operations.

But it is done in single thread in most cases, so single offscreen window can be used for multiple bitmaps. It will also speed up creation/destroying of buffer bitmaps.

[pulkomandy]

Having it in single thread does not prevent nesting multiple drawing operations that require intermediate bitmaps. Moreover it is not possible to resize BBitmaps, which makes it complicated to reuse them in some case.

With these limitations in mind, maybe some caching can be implemented, but if it needs thousands of them at once already now (when they are deleted as soon as possible after use), it will only need even more if there is caching. Good speed improvement, but at the cost of even more ports and memory use.

[X512]

Replying to pulkomandy:

Having it in single thread does not prevent nesting multiple drawing operations that require intermediate bitmaps.

Some kind of switching between bitmaps can be implemented for single offscreen window like it is already implemented for views (BView::_CheckLockAndSwitchCurrent). Offscreen window can have multiple attached bitmaps and switch to bitmap when drawing operation is performed on specific bitmap.