Announcement

Collapse
No announcement yet.

Rekonq 2.1 Web-Browser Brings More Features

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic Rekonq 2.1 Web-Browser Brings More Features

    Rekonq 2.1 Web-Browser Brings More Features

    Phoronix: Rekonq 2.1 Web-Browser Brings More Features

    Less than one month after the release of the Rekonq 2.0 web-browser for the KDE desktop as an alternative to Konqueror, Rekonq 2.1 has surfaced and it brings more features to this open-source WebKit-powered project...

    http://www.phoronix.com/vr.php?view=MTI4NTE

  • zanny
    replied
    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.

    Leave a comment:


  • Awesomeness
    replied
    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?

    Leave a comment:


  • zanny
    replied
    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.

    Leave a comment:


  • Awesomeness
    replied
    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?

    Leave a comment:


  • Apopas
    replied
    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, 02:05 PM.

    Leave a comment:


  • Awesomeness
    replied
    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/

    Leave a comment:


  • GreatEmerald
    replied
    Rekonq and QupZilla are pretty good matches for Razor-qt. Lightweight and Qt-based. So there is a good reason for them to exist.

    Leave a comment:


  • DanL
    replied
    Originally posted by BO$$ View Post
    This browser is pointless. Why does it even exist? Nobody is using it.
    The point is that it's a lightweight Webkit-based brower that's integrated with KDE. Just because you don't use it doesn't mean nobody does (unless you're the only person that exists).

    Leave a comment:


  • pejakm
    replied
    QupZilla is pure Qt web browser which can be compiled with Qt5:

    http://qupzilla.com

    Leave a comment:

Working...
X