Just from your own experience, which option results in the best image quality or performance (or they are the same, no difference)? Enabling high DPI in C2 or using the command line option with XWalk?

—, both of the two ways (enabling high dpi in C2 and using cmd line option with XWalk) are the same in image quality and performance. They are two different ways to let Crosswalk engine use the right devicePixelRatio when painting canvas.

Its noted that in C2, enabling high DPI will reduce performance in crosswalk compiled games. Does the forcing via command line to 1 density work differently so that it doesn't reduce performance?

Either way its good to know the blurry image issue can be easily resolved. Thanks!

—, may I know how much performance impact in high DPI mode? According to my observation, the way by command line option is almost the same as by C2 configuration for high DPI, so they should be at the same performance level.

I managed to sort my issue with regards to signing my apk and updating an older CJS google play store listing.

—

I also get the blurry image issue even on small images. I have to set the high DPI to yes to make smooth graphics for my app. I believe this will give a performance issue on most phones though In CJS all my graphics were fine with that turned off.

—, Mayfly, I managed to set up the test case to reproduce the blurry image issue, and work out a solution to resolve it for Crosswalk.

As mentioned by Mayfly, the image would NOT become blurry if the high DPI is turned on by Contruct2. That is true because, on a high dpi device, the display density is always greater than 1, for example, it is 2.0 on Google Nexus 7, and so window.devicePixelRatio in Crosswalk engine is also set to 2.0. The value of window.devicePixelRatio will be used to draw canvas by C2 runtime if high dpi mode is turned on, to get a more sharp image. In case of high dpi mode is turned off, C2 runtime tries to draw the canvas with the default value 1.0 on a high-dpi screen, as a result, the final image output becomes blurry since the pixels drawn by C2 runtime would be hard-scaled to fit the high-dpi screen dimension.

The solution for Crosswalk is simple, you can pass --force-device-scale-factor=1.0 command line option to Crosswalk engine in assets/xwalk-command-line. Note the command line file is supported from Crosswalk 6.

With the above command line option, the Crosswalk engine force to set the device scale factor to 1.0, and so window.devicePixelRatio is 1.0 accordingly no matter the value of the device density. In this case, when C2 runtime would draw the canvas which can fit the screen dimension without hard-scaled.

The memory consumption is decided by the size of canvas. In case of high dpi mode is enabled, for example, on Nexus7 with 1920x1200 resolution, the canvas size is 1920x1080, while in case of high dpi mode is disabled, the canvas size is 960x540.

Another way to resolve this issue is to enable high dpi mode in C2. Don't worry, it won't consume more memory than CJS. The reason is, CJS has its own implementation for canvas, it internally enables high dpi mode for canvas drawing on a high dpi device regardless of whether it is enabled in Contruct2 project setting.

Has anyone noticed that the battery usage is VERY high using Crosswalk, even when the app is exited and paused in the background?

Thanks for your reporting this issue. Logically, it would not be very high in power consumption since we already have special considerations and handling for power saving, e.g. JS timer pause when switching to background, resource releasing when app is exited.

Could you please upload your workload so that we can analyze further?

—, Mayfly, I still failed to reproduce it with some experiments.

—, I agree with your analysis for the blurry image caused by scaling. If I could reproduce it, I think I can fix in XDK/Crosswalk, at least to provide a option for developer to decide if auto-scaling is needed.

Would you please paste a piece of code to show how do you use the image in HTML file? for example, if viewport meta tag is used, and the css applied to image, so that I can reproduce it easily and correctly.

Hmm, in my debugging text it says "canvas2d" as renderer, in both stable and beta builds but the stable has a better framerate(55 fps vs 32 fps).

The intel app preview the app is using the "WebGL" renderer.

Zhiqiang

I was wondering why the performance is worst in Crosswalk 5, even when both builds are running with canvas2d renderer.

Thanks.

Hi, cesisco, even if canvas2d renderer is used, the performance may be still bad if the HW acceleration for canvas2d is blacklisted on your device. Chromium will also blacklist the accelerated canvas2d on some device, e.g. the older Qualcomm Adreno device, see the link crbug.com/161575. To confirm the gpu feature status on your device, I suggest to use Chrome for Android for help, you can type about://gpu to check the output for Canvas category.

I've tested this on lots already, you can reproduce it with just a blank layout (1280 x 720 pixels), one image sprite with some spritefont text, then compile with XDK/Crosswalk and CocoonJS and compare the result.

At this point I suspect 2 possibilities: 1) Letterbox scaling, because my test device is 1200p and not 720p that my games are made at. I say this because CocoonJS doesn't have proper scaling, it just keeps that aspect ratio and have black/empty bars on bottom and right if the display is not matched. 2) Rendering quality/filtering is low on mobile chromium.

—, thanks for your information. I try to reproduce it on Nexus 7 (with 1920x1200 resolution) according to your instruction, but unfortunately, I failed to reproduce the blurry image as you said, I am not sure if I set up the same env as yours. Below is my approach for reproducing:

1. Use a 1280x720 image as <image> in a HTML page and explicitly set the image width and height to 1280px and 720px, or

2. Use the same image as the background of body by the following CSS:

  body {
       background: url('a.png') no-repeat fixed;
       background-size: cover;
  }[/code:2ggagmw3]
In both of the above ways, the image can be auto-scaled and kept the same aspect ratio, but it would NOT become blurry as you mentioned. 
So would you please show me how your image is used? e.g. its style and DOM element with the original image. Thanks.

hmin, thanks for the info, I will take a good look at it soon. But do you have any news on why the startup screen acts weird?

If I am holding my phone in portrait or landscape mode while the splashscreen is showing, it displays a black and white screen. If I don't change my phone's orientation when the splashscreen is showing, just before the game starts it shows a black screen for a short time, but very noticable.

Regarding to the splash screen issue, we are looking into it and will update it once we make some progress. Thanks.

— Is there a way we can prevent the phone from sleeping? I didn't see that issue on your online spreadsheet thingy.

KFC, rekjl, does the plugin (link is blocked, you can search 'phonegap-powerManagement-plugin' in Google) meet your requirement? It can make application keep running for a long time without user interaction.

Hi, —, Thanks for your feedback. I am from Crosswalk team and working on Crosswalk development. I'd like to look into the issue your report. It would be better if you could upload your apk or a simple way to reproduce this issue.

IntelRobert

In regards to the visual clarity (or lack of), this was raised awhile ago, is there a solution upcoming?

I compared the same build and scene with CocoonJS and the latest XDK, there is a large drop in clarity in the XDK compiled game compared to CJS. Performance is very similar between both.

These screenshots are captured from my device running the game, LG G-Pad 8 with native 1920 x 1200p resolution.

Hi, cesisco, I am from Crosswalk team and working on the Crosswalk development.

The lower framerate is very likely to be caused by the fact that we only ignore gpu black list for IA platform from Crosswalk 5, and it won't do any additional thing for ARM platform to avoid some crash which is reported from Construct2 user, see XWALK-934 in Crosswalk Bug JIRA.

From Crosswalk 6, we allow the web developer to append command line options by themselves, for example, you could append '--ignore-gpu-blacklist' in 'assets/xwalk-command-line' file, and Crosswalk runtime will load this cmd option file firstly before launching your app.

IntelRobert, the audio lag in the Crosswalk 5(beta) build is ok, but the overall performance in every other aspects is very bad in my games, the framerate is almost the half comparing to Crosswalk 4(stable).

So i´ll wait until Crosswalk 5 goes stable, and hope everything runs smoothly.

Thanks

> Our build system gives you the choice of crosswalk 4 & crosswalk 5. The latest app preview uses crosswalk 5. Since you say that App Preview does not have the lag, then I am hoping that it was a problem fixed in crosswalk 5. Please check that you are using crosswalk 5 by going to the bottom of the details tab in the build dialog.

>

> If crosswalk 5 has the problem, then please PM a capx file that shows the problem.

>

>

> >

> >

> > IntelRobert, hi, here's a video with a comparison of the audio latency in the device:Intel AppPreview:less than 30 millisenconds

> > Crosswalk Apk build: 234 millisecods

> >

> > I guess the problem is not with my device, since it play synced in the App Preview.

> > In the Chrome Browser the latency is around 34ms, but i have other problem in Chrome for android, the sound is

> > playing on the earpiece and not on the speaker, i mentioned that on this topic :I can send you the Apk build and my device specifications, but note that the audio lag occurs in every project i have.

> > Thanks

> >

>