Hi All,

I think updating only txt results isn't the best idea now. It can be very very
confusing if we leave broken pngs in the tree. And I can't see any pro to do it 
...

Now Qt 4.8, Qt 5.0-WK1, Qt 5.0-WK2 (not QRawWebView, but QQuickWebView based 
WTR) have
same results. (except only ~500 tests). (But unfortunately png results are 
outdated,
and they changed with this testfont update. We don't run pixel tests, but pngs 
are
very useful for gardening. Determining if a new result is correct or not is 
impossible
if you can see only the rendertree dump. But it is quite simple if you see png 
results.
Additionally we (Szeged guys) always update png results too when we update txt 
results.
Updating txt or txt_and_png is only an option, it doesn't need additional 
effort. Updating
only txt results needed extra effort, because you have to revert png changes 
after you
updated results with rebaseline-server.

I think the new QRawWebView based WTR is an orthogonal problem. I can't see how 
can
QRawWebView and QQuickWebView results are different? They should match if there 
isn't
bug in one of them. Or in the case if different results is expected/acceptable, 
we
have to maintain results for Qt 5.0 WK1 and Qt 5.0 WK2 too. So we disn't have 
to rebase
anything, but adding qt-5.0-wk2 specific pngs if we added Qt 5.0 WK1 pngs now.

br,
Ossy

[email protected] írta:
From: [email protected] [[email protected]] on behalf of ext Balazs Kelemen
Are we sure we need pixel results at the moment? For Qt 4.8 it seems to
be unvaluable to me, I don't expect anybody want to do pixel testing
with 4.8. WebKit2 is another problem, because a reliable pixel testing
infrastructure is just under progression. Maybe the new mechanism with
window snapshots will produce slightly different results, in which case
we would have to rebase the results again. I propose not to consider
pixel results as a mandatory part of this rebasing process.

This makes sense to me. Committing a massive amounts of PNGs should be done after we've decided what we want to do with them.
I propose we finish this rebase with text results only, then finish switching 
to the window-snapshot mechanism for the pixel results, and meanwhile figure 
out our pixel testing/gardening strategy - e.g. pick one bot (webkit2-linux) 
that continuously runs pixel tests and keep its results current, continuously 
gardening/skipping whatever gets broken to keep track of pixel regressions.

Once we have the strategy in place, the rebaseline text results from the current effort, and the window-snapshot mechanism, we should then rebaseline the PNGs.
No'am
_______________________________________________
webkit-qt mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo/webkit-qt

Reply via email to