Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Rekonq 2.1 Web-Browser Brings More Features

  1. #11
    Join Date
    Dec 2010
    Posts
    1,264

    Default

    Quote Originally Posted by molecule-eye View Post
    I remember there was a plan to get Rekonq working with Chrome extensions. Is anyone working on this?
    Yes, rekonq 3.0: https://adjamblog.wordpress.com/2012/07/23/experiments/

  2. #12
    Join Date
    Mar 2009
    Location
    Hellas
    Posts
    1,120

    Default

    Quote Originally Posted by Ericg View Post
    I used it for a few days on my laptop, its a very nice, simple little browser with no major complaints except one: memory usage is a bit high.
    Extremely slow rendering, unfortunately. In a forum with a lot of emoticons and youtube posts is completely unusable while both Firefox and Chromium run without problems. Qupzilla is slow as well but not unusable as Rekonq.
    Last edited by Apopas; 01-30-2013 at 02:05 PM.

  3. #13
    Join Date
    Dec 2010
    Posts
    1,264

    Default

    Quote Originally Posted by Apopas View Post
    Extremely slow rendering, unfortunately. In a forum with a lot of emoticons and youtube posts is completely unusable while both Firefox and Chromium run without problems. Qupzilla is slow as well but not unusable as Rekonq.
    As if two browsers which use exactly the same QtWebKit version could have any performance differences…

  4. #14
    Join Date
    Dec 2012
    Posts
    588

    Default

    Quote Originally Posted by Awesomeness View Post
    As if two browsers which use exactly the same QtWebKit version could have any performance differences…
    I could throw for(int i = 0; i < 1000000, ++i) { fprintf(foo, "Lalalalalalaa\n") } into the main loop of either and have the thing crash and burn. Just because the rendering backend is the same doesn't mean there isn't some inefficiency in the thousands of LOCs surrounding it.

  5. #15
    Join Date
    Dec 2010
    Posts
    1,264

    Default

    Quote Originally Posted by zanny View Post
    I could throw for(int i = 0; i < 1000000, ++i) { fprintf(foo, "Lalalalalalaa\n") } into the main loop of either and have the thing crash and burn. Just because the rendering backend is the same doesn't mean there isn't some inefficiency in the thousands of LOCs surrounding it.
    How would different page rendering performance just because the toolbar buttons are drawn by different applications even be possible?

  6. #16
    Join Date
    Dec 2012
    Posts
    588

    Default

    Quote Originally Posted by Awesomeness View Post
    How would different page rendering performance just because the toolbar buttons are drawn by different applications even be possible?
    • qtWebKit is an imported library both use, and have setup involved in the application including some online configuration of the environment.
    • You can allocate as many threads or as few as you want to the rendering backend (though there are very few ways to get out of serially parsing html, and javascript is always single threaded) which impacts performance.
    • Since it is a shared library and not a dedicated subprocess, you could be trying to run the renderer from your main application thread, which would propagate exactly the problem I pointed out. If other aspects of that execution stack are slow, the rendering would also be slow.
    • You can set allocator limits throughout the application to control the behavior of the renderer.
    • You can override standard library functionality or any external behavior the renderer uses that could slow it down or speed it up.
    • You can override parts of the renderer in your own code, since in qt using webkit is just a module you import.
    • The caching behavior of webkit is entirely controlled by the host process. This is probably the most major cause of slowdowns when two applicaitons share the same webkit.


    There are a lot of ways to influence the execution speed of a component an application is importing. In an even more generic sense, you could just reduce the scheduler priority of your render threads and it will just get less cpu time inherently, but you can do that out of the program too.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •