Pseudo-classes not working

[barotto]

I'm having issues with pseudo classes in the invaders demo. Look at the main menu:
with libRocket:

with RmlUi:

It seems like the :hover pseudo-class is not selected as specified in the assets/invaders.rcss file.

Same thing for :active and :checked for other input elements:
libRocket:

RmlUi:

[mikke89]

That's strange, are you on master?
I just tested it, and it's working fine for me.

[barotto]

Yes I'm on master. So it's only on my end? That's odd...

[barotto]

I'm blaming pseudo-classes, but could it be releated to texture coordinate calculations?

[mikke89]

It's really hard for me to say as I can't replicate it.

Maybe you can try to isolate where things went wrong, something like git bisect?

Also, you could also try the performance branch to see if it helps. There are quite some changes to how things are dirtied and updated which may or may not help.

[barotto]

I tried the performance branch and the issue is not present there.

I also bisected master and, after a bit of tribulation (VM installing, patch backporting, ...), I identified the culprit:

b86efd039bafd77940a9aebe01ca7fa9f33326a0 is the first bad commit
commit b86efd039bafd77940a9aebe01ca7fa9f33326a0
Author: Michael <michael.ragazzon@gmail.com>
Date:   Tue Aug 21 23:59:43 2018 +0200

    Performance: Change several maps and sets to unordered_*.

:040000 040000 79ed19c226ced5701f6043bbb7dd7b2976f26dc5 fad2e1d0103559bd038ade3d7db33f963a2451e5 M	Include
:040000 040000 fb4a6cc5d062bf1d544c333673deab18eb4d6353 fc9dd17cdabd62bc0c28499bb417abad72691392 M	Source

This commit is rather large so I'm afraid my investigation ends here.

[mikke89]

Thanks a lot, this is really helpful. I know it can be a pain to bisect back in time like that.

Okay, so what I think is happening is that one (or more) of the containers are assumed to be sorted during some operations. After changing to their unordered_* variants, this assumption was broken. Now the order depends on the standard library and compiler which may explain the differences we are seeing.

I did identify some places where things should be ordered while working on the performance branch, which is why it may be working again there.

My primary suspect is the PropertyNameList, you can try changing it back in Types.h from:
typedef std::unordered_set< String > PropertyNameList;
to
typedef std::set< String > PropertyNameList;

Other possible candidates could be the PropertyMap, Stylesheet::NodeIndex, and, uhm, actually I'm putting all my bets on one of those three 🎲 :)

[barotto]

Yep, changing PropertyMap to std::map did the trick.
We use different STL implementations so this explains it.

(and all this compiling clearly explains to me why I need one of those new 16-core Ryzen 9 ... 🐌 🖥️ )

[mikke89]

Awesome, good job finding it :)

Let's replace it on master while we wait for the performance branch to merge. I'll have another look at the performance branch to make sure we don't have any issues there.

I can only imagine, looking at CPUs myself these days, the new AMD stuff looks really promising.

[kim8823]

Seems like they are broken again...
:hover and :active work, but not e.g. :first-child and :last-child.
I'm on the 3.2 release.
Already tried to change the PropertyMap to a std::map, but no success.

[viciious]

Seems like they are broken again...
:hover and :active work, but not e.g. :first-child and :last-child.
I'm on the 3.2 release.
Already tried to change the PropertyMap to a std::map, but no success.

Try disabling third party containers in CMake options and see if that helps maybe.

[kim8823]

doesn't make a difference

[mikke89]

I'll take a look at it, sounds like it's related to pseudo classes if :hover and :active is working.

[mikke89]

Okay, this was unrelated to the original problem. There was an issue where structural pseudo-classes required parenthesis to properly parse. This should now have been fixed.

Thanks for reporting the issue :)