samsung / castanets Goto Github PK

On castanets_63 branch, GPU channel is enabled and GPU rasterizing and WebGL are able to be run. (MM video is not still shown with GPU)

Now, migrating GPU channel to 69 is necessary, but the implementation of shared memory for castanets was changed since castanets_69.

The current implementation of syncing shared memory between a browser process and a renderer process is acceptable for 1:1 scenario
However, further implementations and modifications are required for syncing shared memory between a browser process and multiple renderer processes (1:N).

Enable Accelerated Compositing using GL.

Turn on DCHECK.

Adding the fallback function itself makes sense. In addition, two types of child process connections can be run simultaneously in one browser - TCP/IP based castanets connection and IPC based existing connection.

Currently we use software rasterization (Bitmap raster) on renderer since renderer gpu channel is not up yet.

This task is to make accelerated composition up until with bitmap raster until renderer gpu communication is setup.

There are two possible approaches:

(i) Adapt GL Renderer to composite sw pixels on gpu.

(ii) Incorporate a new gpu compositor based on SkiaRendeer (from upstream)

This is an issue that occurs when desktops are connected to each other.
In sites including media such as youtube, a video tag plays audio but it shows white.
Enabling gpu channel on Castanets doesn't handle the video scenario.

Run on Android.

Run Unit-Tests.

Integrate SDM with m69 and enhance usability for Linux, Tizen, and Android.

Handle Shared Memory for Audio.

[Precondition]
X11-forward setting from remote PC to local PC.

[Case]

1. Run browser process in remote PC and forward graphical result to local machine
2. Run renderer process in local PC
3. Navigate to any webpage such as youtube and tile break is observed.

Remove the workaround code below.
content/browser/child_process_launcher_helper_linux.cc:121

#if defined(CASTANETS)
  if (!base::CommandLine::ForCurrentProcess()->HasSwitch(switches::kEnableForking)) {
    Process fake_process;
    fake_process.process = base::Process(7777);
    return fake_process;
  }
#endif

See #153 (review)

• Investigate whether GpuChannelMsg_RequestSyncTransferBuffer can be removed.
• Analysis for Sync call minimization

To meet performance requirement, This Epic include below activity

• Measure Performance for remote mode
• Analysis performance bottleneck
• Add Tactic for performance enhancement

Expected performance is scoped like below.

1. Loading performance
2. graphic performance

[Build Bots] Daily binary for Android.

Handle Shared Memory for Discardable Shared Memory.

Cookie policies and cache policies in current Chromium architecture may not be suitable for Castanets.
For instance,

1. Should fetch cache from browser-side? Would it be faster than reading from server-side?
2. Should cache be on renderer-side? What if renderer device changes?
3. Should we drop cache policy and always read from the server?

We need to think and decide the right policy for castanets.

Fix Build Breaks on Android.

Automatic Launch of Network Process on Renderer Device.

Check that service discovery manager is working properly on Linux.

architecture for GPU rendering path needs to be analyzed and enabled

1. Enable Accelerated Compositing using GL. : #16 (comment)

2. Feasiblity to use accelerated composition on browser process with bitmap raster. : #17 (comment)

3. Feasibility of enabling gpu path for renderer using OOP Rasterization. : #18 (comment)

Migrate SDM from 63 and Check If It Is Working Properly with 69.

We sync the entire shared memory without considering the region of rasterization when updating tiles. Supporting partial synchronization expects to improve performance by transmitting minimum data bytes.

[Build Bots] Build Test for Pull Request.

• Some tiles show black or stale bitmaps.
• It can be easily found on complex web pages. (www.daum.net)
• It doesn't occur if preventing the resource manager from reusing tile resources.
• It occurs in both SW and GPU compositing.

Describe the bug
IPC communication fails between a browser process and a renderer process.
Renderer terminates abnormally.

[1380:1380:0718/110214.792457:WARNING:storage_partition_impl.cc(839)] Killing renderer: illegal localStorage request.
[1380:1383:0718/110214.792535:ERROR:render_process_host_impl.cc(4526)] Terminating render process for bad Mojo message: Received bad user message: Access denied for localStorage reques
[1380:1383:0718/110214.792546:ERROR:bad_message.cc(25)] Terminating renderer for bad IPC message, reason 123
[1380:1383:0718/110215.003745:WARNING:render_frame_message_filter.cc(536)] Killing renderer: illegal cookie write. Reason: 78
[1380:1383:0718/110215.003826:ERROR:bad_message.cc(25)] Terminating renderer for bad IPC message, reason 78

To Reproduce
Steps to reproduce the behavior:

1. Launch a browser process (./chrome https://www.naver.com)
2. Launch a renderer process (./chrome --type=renderer --server-address=127.0.0.1)
3. Navigate using URL bar to Google.com -> Naver.com -> Google.com
4. See error

Expected behavior
Should open a webpage without a renderer termination

Desktop (please complete the following information):

• OS: Ubuntu 16.04
• Version: Castanets 69

[Build Bots] Daily binary for PC(Linux).

As open source version goes up, continuously rebase castanets baseline following chromium latest version.

Handle Shared Memory for Font.

suyambu.rm Suyambulingam Rathinasamy Muthupandiadded a comment

Current Status:
With distributed shared memory gpu channel is enabled http://suprem.sec.samsung.net/jira/browse/TIZENWF-984

https://github.com/suyambulingamrm/Castanets/commits/castanets_63_nfs.

With this one-copy raster model works fine on renderer. (different pc)

Currently Canvas2D, WebGL, doesnot work due to some sync issue on command buffer. (observed only on different pc case)

The reason seems to be some of the results for GL command(GetBucketStart, GetBucketContent) which browser posts to renderer is not received properly due to sync problems. Checking further on this.

Handle Shared Memory for Ruleset.

Sub-task of #111
File scheme resource should be loaded on Browser side device even when NetworkService is enabled in renderer side device.

• Move resource loading to the renderer process

The module of resource loading is located and run in browser process.
It causes performace degradation because resources are sent to renderer process. This looks unnecessary so we need to move the module to renderer process.

There are two choices to solve this issue.
1.Attach a loader module to renderer process.
Renderer process should have all objects related to resource loading. Renderer should create classes, variable and so on.
The problem is that most objects included in a loader module are based on browser process, and it may make too many code's diff and huge works.
2.Run a loader module on local browser process(thread) on the device including renderer process.
For example device A has browser process and device B has renderer process. But in this scenario, device B has full chromium as single process. The loader module can be run on local browser thread and resources are shared with renderer thread by SharedMemory.
This case also has problems, First, renderer process should connect with two browser process (local and remote). A new IPC construction is needed. Second, this case may violates an original concept.

The aim of the task is to rebase/migrate distributed webengine feature to M63 upstream version.

Opensource version:

https://github.com/Samsung/Castanets/tree/castanets_63

Castanets allows shared memory to work properly between browser and renderer processes running on different devices. In order to make that happen, we've added implementations to allocate valid shared memory and to synchronize them between processes. For basic web browsing, these implementations have been priorly applied to modules such as resource loader and shared bitmap for SW compositing. In addition to these modules, there are many uses of shared memory in chromium, for example, visited links, ruleset files and etc. Most of them are being blocked by workaround or not working at all. This Epic is to find out these kinds of modules, modify them to work or disable them properly.

Handle Shared Memory for Visited Links.

[Issue]
When opening youtube.com or paypal.com, Castanets for Linux hangs.
Seems to be related to the media pipeline issue.
The browser-side log is
WARNING:audio_sync_reader.cc(228)] AudioSyncReader::Read timed out, audio glitch count=11
WARNING:audio_sync_reader.cc(228)] AudioSyncReader::Read timed out, audio glitch count=12
....
The renderer-side log is
MediaEvent: MEDIA_ERROR_LOG_ENTRY "FFmpegDemuxer: open context failed"
MediaEvent: PIPELINE_ERROR DEMUXER_ERROR_COULD_NOT_OPEN
Note that renderer-side log is not always printed

[HOW TO REPRODUCE]

1. Run browser process with following options enabled
   --aggressive-cache-discard --disable-application-cache --log-level=0
2. Run renderer process
3. In the URL bar, type youtube.com
4. In the URL bar, type paypal.com
5. repeat from 3

@Sunwoo-Nam Please check the above issue.

Enable Network Service on Renderer Device to load the resource directly from Renderer without transferring resources between Browser and Renderer.

To guarantee basic stability need to define policy of feature landing.
We can consider some of below candidate

1. Make smoke test scenario and let developer carry out test before landing meaningful feature.
2. Define daily test case(auto or manual) and based on daily binary let test engineer carry out TC and early detect regression.
3. Currently we didn't accomplish enough stability level. so need to make periodical exploration test schedule

The project name was decided "Castanets", so the macros and the flags should be changed.

Sub-task of #111
Shared memory handle should be passed through Unix Domain Socket, not TCP socket to transfer resources between Network Service and Renderer as Zero Copy.

Dev infra includes following tasks

1. Build test for PR on Github
2. Nightly build for different platforms such as Linux and Android
3. Run unit tests on CI when unit tests are runnable
4. Auto-perf tests may also be included

Currently, you can see that sometimes some resources, especially sub-resources such as images, are not displayed properly or some Javascripts print weird error messages. I cannot be one hundred percent sure, but it could be caused by the issue described below.

The problem is caused that in data pipe the consumer can read before the producer completes the write. This is because the resource loader's data is being delivered asynchronously. As looking at BrokerCastanets::SyncSharedBufferImpl(), you can see that the method does not wait for BUFFER_SYNC_ACK when it is called from the IO thread. The resource_loader's data pipe receives and writes data on the IO thread, which causes sync() calls on the same thread.

Handle Shared Memory for Histogram.

WebGL and 2D Canvas support on Castanets.

Upstream OOP Raster. (Since M62)

https://groups.google.com/a/chromium.org/forum/#!topic/graphics-dev/jQ-Q1qrUOlo

https://docs.google.com/document/d/1vsJsk1zGSagxxBggd8j5G9u0rMzD1NTaQWgEbUabEvY/edit#

https://bugs.chromium.org/p/chromium/issues/detail?id=757605

Current model:
During gpu rasterization/one copy rasterization:
tile playback happens on renderer.
Texture upload commands are transferred to gpu process (one copy)
gl commands are transferred to gpu process/thread (gpu raster)
Texture resources are known to renderer and can be accessed using gl commands via command buffer.

OOP raster: (gpu rasterization)
Display lists (the paint commands/ops for tiles) are serialized and transported to gpu process.
Tile playback, gl command execution happends on gpu process.
Renderer doesnot need to be aware of gpu resources.

OOP raster is implemented through gpu command buffer.
Renderer sends below raster commands to gpu process for rasterization
BeginRasterCHROMIUM, RasterCHROMIUM, EndRasterCHROMIUM

Challenge:
Establish gpu command buffer (gpu channel) between renderer<->gpu process which is dependent on shared memory.

Paint Op serialization also seems to be based on shared memory.

The advantage may be gpu resource handling is fully done on gpu process on oop raster, renderer doesnot need to take care of those resources..

A rough idea.
Add wait(), symmetric to sync(). Call sync() at the writing point and wait() at the reading point. Writers are not blocked, and readers wait a minimum amount of time to access shared memory.