Review Request 113415: Port KSplashQML to Qt5 + remove XLib stuff + replace x11eventFilter with DBus interface (Wayland++)

[Thomas Lübking]

> On Oct. 24, 2013, 4:17 p.m., Fredrik Höglund wrote:
> > What's the cold startup time like for KSplashQML compared to KSplashX?
> > 
> > Let's not forget that the reason KPlash was rewritten to only depend on
> > X + libjpeg + libpng was so that the startup time would be limited by
> > the time it takes to load the images for the theme.
> >
> 
> Martin Gräßlin wrote:
>     but that's a long time ago, isn't it? So Moore's Law... Anyway could be interesting to do such comparisons on spinning metal.
> 
> Ivan Čukić wrote:
>     We haven't done any real benchmarks, but it doesn't seem to be noticeably slower.
>     
>     It should not slow down the boot - if it does start slower than ksplashx, it speeds up loading the workspace for the same amount by having Qt preloaded.

Isn't the splash screen supposed to cover (also) those loading costs?
If the splashscreen took like 5 seconds to load but then could finish in 500ms, we would simply not require a splash screen in the first place.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113415/#review42299
-----------------------------------------------------------


On Oct. 24, 2013, 2:19 p.m., Martin Klapetek wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/113415/
> -----------------------------------------------------------
> 
> (Updated Oct. 24, 2013, 2:19 p.m.)
> 
> 
> Review request for kde-workspace and KDE Frameworks.
> 
> 
> Repository: kde-workspace
> 
> 
> Description
> -------
> 
> Ports KSplashQML to Qt5 and strips any XLib stuff. Martin G. suggested to try if it would simply work without XLib/XCB bits at all and it does work in testing mode, I'm unsure if it also works after actual login, but I don't see why it wouldn't.
> 
> KSplash was also receiving the stage messages via XAtoms, which I replaced with simple DBus interface. That means that all the parts in the login sequence need to be updated (I'll do it) to emit dbus signal instead of sending X message. I used the same API as the XAtoms were using, but let me know if you think this could be changed. In some future I'd probably also change the stages resolution as it's not too robust and does not help paralelization much. I have a plan in my head but that's for another commit.
> 
> I'd also like to remove the old KSplashX and port its default theme to QML and provide together with KSplashQML as "Classic" or "KDE 4" theme.
> 
> 
> Diffs
> -----
> 
>   ksplash/ksplashqml/CMakeLists.txt 8cd5305 
>   ksplash/ksplashqml/SplashApp.h 3c55be9 
>   ksplash/ksplashqml/SplashApp.cpp 7c528d0 
>   ksplash/ksplashqml/SplashWindow.h 9680c1e 
>   ksplash/ksplashqml/SplashWindow.cpp 4417643 
>   ksplash/ksplashqml/SystemInfo.h 7a74554 
>   ksplash/ksplashqml/main.cpp c2722ab9 
>   ksplash/ksplashqml/org.kde.KSplash.xml PRE-CREATION 
>   ksplash/ksplashqml/themes/Minimalistic/main.qml e4fb8b8 
> 
> Diff: http://git.reviewboard.kde.org/r/113415/diff/
> 
> 
> Testing
> -------
> 
> Theme successfully loads, displays fullscreen (Plasma panels are not covered, not sure why), all stages passes, then it terminates itself.
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20131024/2258f3f1/attachment.htm>