I'm developing my project in Codename One. UI creating from code, not GUI Designer. Application consists of three forms, as navigation I use Hamburger sidebar. The emulator works fine, but the builded application works very slow. Application was tested on Android. The degree of brake application depends on the number of components in the form. The situation has changed a little after we changed android.asyncPaint to false, but the operating speed remains slow.
Above all, Hamburger sidebar animation works strange. At first shows previous form, and then only shows the selected form. But this problem is not as important as the terrible brake application.
In 9 our of 10 cases this is caused by developers using gradients which are notoriously slow. It can also be triggered by tiling very small images or too many layers of transparency.
We have a performance monitor tool in the simulator that exposes some of these issues. You should also watch this video which covers most performance issues: http://www.codenameone.com/how-do-i---improve-application-performance-or-track-down-performance-issues.html
Related
So I have to give a presentation of a website I made. So I didn't have time to make it responsive. I have used position:relative and pxunits in margins and all. Will it change layout of website if I use duplicate option in windows 10 project.
If the projector has a resolution similar to a regular computer screen, it won't make a difference.
We were able to use automation tool and it was able to identify html objects on Winforms while on WPF it does not since it is rendered as an image.
My main question is what does Winform CEFSharp uses to render and why WPF not able to use a similar rendering mechanism?
Warning: it is a very generic answer. I briefly looked at CEF source (briefly - 3-5 minutes) and the rest are my guesses based on my own WPF/WinForms interop experiences. I've had quite a few. I also played a bit with early Chromium builds. However, all of that was a few years ago, so it may simply be out dated. Maybe Chromium has now first-class WPF support. I have not found any information about that, but if this really happened, I encourage you even stronger to follow the last paragraph.
--
I doubt that there is any reason behind this other than time-cost to implement -
either on CEF or Chromium project.
WinForms and WPF are totally different GUI frameworks, written in different eras, using different architectures, different rendering techniques, different platform features, etc. This is as different as it can be, down to the idea of a "Window" itself.
In WinForms, almost every control is a separate small window-like thing, has a system-wide handle, has a system-tracked region, etc. All controls render themselves almost directly by unmanaged win32 GDI+ functions.
In WPF they don't. In WPF there's only one handle per whole window, controls don't render themselves. Instead they have a definition of their "look" and the WPF renders them to the 'surface', which is then blitted/streamed (sorry, dont remember) to target device.
That's true that CEF uses different approaches. For WinForms they make heavy use of a 'browser component' taken directly from Chromium, for WPF they render to bitmap and show/update the bitmap periodically.
Why? My guess is that it's because Chromium already provided a COM/OCX/ActiveX/whatever component, and WinForms can use it almost directly, thanks to the everything-has-a-handle "feature" - if you can call it a feature - one of the goals and successes of WPF was to eliminate that.
However, I don't think that Chromium at that point of time provides any such component for WPF.
If it does not exist, then for WPF there are only two options - one could embed the WinForms component in WPF window through a special 'host' intermediate control, but that actually hits the performance and also has many problems when some advanced rendering features (like movie streaming) are used. Diagnosing and fixing them is complex, hard, and even unstable (crosshosted components behave very differently on different windows and .net versions, even on .net patches sometimes change them, it can work one one, and freeze on other, hang and render as black on next and cause a blue-screen on another)
Other option for WPF is to use the "offscreen" mode. Chromium can render to a bitmap, so why not. Render to bitmap, and display that. Simple. Quick. No problems.
So, I'd say, it all boils down to a famous quote from Eric Lippert:
The question is "why does [snip] not have this feature?" The answer to that question is always the same. Features are unimplemented by default; [snip] does not have that feature because no one designed, implemented and shipped the feature to customers.
It's great we can at least display Chromium in WPF apps. If you think it can be done better and that it's worth doing, it's open source, feel free to implement it - if not in CEF, then in Chromium itself.
So I'm not really sure how to explain this but I will try my best.
I created a jsfiddle: https://jsfiddle.net/xghar755/2/
As you quickly hover over each text, you can see that the background color changes. This is just a simple div with a css hover property. Here is the kicker though, go to your address bar and type in any letter and you get a drop down of items, like so.
Now, quickly hover your mouse over the items in the dropdown. And then go back to the jsfiddle and hover your mouse over its items. You can tell that the chrome versions` background color feels more responsive. It's rarely noticable, but I can tell. Why is that?
Is this because Chrome's a Native application that doesn't rely on CSS or the DOM? If so, does this mean that native apps are generally more responsive in user interface applications? Thanks ~
Chrome is a software program running on your device. jsfiddle is, in part, a program that communicates with Chrome via the internet. Each transaction between the browser and jsfiddle takes tens of milliseconds, perhaps hundreds, and there can be a multitude of back and forth operations to serve one page and its in-betweens. In addition, Chrome is written in a language that runs in your machines native processing language while communication with jsfiddle is all interpreted by Chrome first, not to mention some processing is done on the jsfiddle server before being sent to your browser.
tl,dr; Programs running on your computer can do things a lot faster if they don't have to communicate with other programs over the internet.
I am working on a project including WPF and OpenNI library with sensor usage. My application is very simple, I am getting hand points from sensor device and drawing two rectangles using data binding. When I'm launching my app, rectangles are drawn with very big lag, but strange thing is, when I start WPF Performance Suit, lag suddenly stops and application is working perfectly.
My question is, what WPF Performance Suit is doing to running application and how I can recreate the same behavior in code without using this program?
Thanks for any help.
I'm retro-fitting a website for Mobile First Responsive Design (MFRD). My question is - how far do you go with the "Mobile First" part?.
For example - on the homepage I plan on having a list of upcoming events, say 4 or 5. On the mobile version I thought 2 would be enough to save screen real-estate. Should I load the other events in dynamically for the larger views, or should I just hide them since it will only be a few elements anyway?
Loading them dynamically for larger sizes means I have to attach an event to the window resize which typically gets fired every pixel. Even though I can offset that with Timeout, that's still a lot of client side checking is it not (even though it's not like users are constantly resizing their browsers).
I mean, even though you're designing for mobile first, you also have to consider the larger sizes right? Obviously larger JavaScript libraries and other assets that are needed for larger only you want to pull in later and not load for mobile - but how crazy do you want to get with the bandwidth saving?
What is the target market for the website? Are you making a completely responsive website that encapsulates smartphone to desktop? Or are you just concentrating on smartphone to tablet?
Mobile First really just means start your styling and content views at the smallest form factor and work up as the device dimensions get bigger. HTML, CSS (media queries) and jQuery all play a part to expand the UI and manipulate (show/hide) content elements as the browser gets bigger.
Take a look at Smashing Magazine, their responsive layout is one of the most extensive I have seen so far, it will give you an idea of how far you can take the MFRD or DARL (Device Agnostic Responsive Layout) methodologies.