Yeah, I realized that. I haven't had much time for anything in the past few weeks. Hopefully it will improve and I can try to debug what is going on somehow.

Finally got back to testing the issue. CapsLock/NumLock do not affect this problem. I am on a fully up to date Arch Linux. Not to sure what to check.

They are not exactly the same refresh rate. One is 59.70 and the other 59.97 (yup). I wonder what happen when they diverge for long enough and we end up with one screen ahead of the other in term of frame count as after 5s at full refresh rate, it would be a full frame of difference. That could be the beginning of an explanation too.

I haven't tested yet, but just in case, I have a dual screen setup. Could it be that we are getting a vsync event for each screen, while each screen would have its own monotonic clock, if mixed, maybe there would go backward?

I will check the E logs and see if I see anything meaningful there.

This has become extremely weird. I have just updated my computer with latest efl and enlightenment. I get some kind of vsync timeout somehow. Basically after some time a desk will stop updating. To get the update back, I either have to trigger enlightenment internal window to be displayed (menu, config, whatever) or switch desktop and it will unstuck the rendering. My past change on disabling vsync in Enlightenment or using the export environment variable do not help anymore. No idea at all where to look for what is going on. Looks like either a timeout somewhere or a driver that doesn't notify Enlightenment correctly.

I have commented out that line and still see the problem. I hadn't updated my efl in a while before that, so it could be change in the vsync code in efl that went in early February. I would have to see if any of those are the culprit.

Ok, will try that this evening and let you know.

As long as expedite test pass and everyone comments has been addressed, I think this is good to go. The thread API is not used by EFL in the hot path, so that part is not the important bit. Maintenance and fitting into the host OS is more important.

In D12151#232371, @jptiz wrote:

In D12151#232370, @cedric wrote:

This is really not ideal. A few feature will be broken when porting an EFL apps that use eio/efl_io_model/filemanager to Windows. Isn't it possible to get some of the feature of efreet to work on the platform you are working on?

I think I can see your point but it is not that clear to me how things would break. Could you give me an example just to understand?

This is really not ideal. A few feature will be broken when porting an EFL apps that use eio/efl_io_model/filemanager to Windows. Isn't it possible to get some of the feature of efreet to work on the platform you are working on?

Your benchmark seems to indicate that the new version result in more work and just the CPU clock got run at higher frequency which made it faster. Could you do your benchmark by running your CPU at full fixed speed just to be sure?

As said in a previous PR, would be nice to refactor this.

Indeed, I always hide my tab.

Try under valgrind with --trace-children=yes and EFL_RUN_IN_TREE=1.

Except for the minor cosmetic of the .h file name not matching the function name, I am good with this. You might want to add a _unregister function as some of the register could be done in a module and disappear at any point.

In D11119#213811, @Hermet wrote:

@cedric "turnoff the ability to update theme files" What do you mean by it?

This is kind of a weird series of patch, removing LayoutFactory and then readding it. I guess it allow for less code to write. Anyway, seeing the code like this now, it looks like we can do slightly better.

rebase

rebase and expose a pointer from the accessor.

rebase

rebase

rebase

rebase

rebase

Ok, in that case, then I don't think this is a correct patch set. Is there documentation somewhere for this?

This is I think the other way around or I miss understood eo. What do we expect from accessor<structure>?

rebase

rebase

rebase

rebase and address comment

rebase

rebase and address comment

rebase and address comment

rebase and address comment

rebase and address comment

Yes, it is resolved. Twitter bug report is the future :-)

As long as you do not replace layout factory, but add a new generic factory which layout inherit from, yes.

So during the initial stage of Efl.Io.Model, it does start by listing all the files in a directory. This could then be batch notified to a composite Efl.SortedModel that would then sort them out and insert them relatively to each other and to the content of the SortedModel.

Basically that would be a batch insert at one position. This is doable, but I doubt it would be very useful.

I think that this model can have two strategy for the sorting. On the first notification of a child being added or if the count > 0 when the compositing is done, the model batch fetch all the child of the composited model and sort them using a merge sort. The idea would be to keep just an index mapping of which child of the sorted model map to which child in the composited model.

I am also not saying this is mandatory, but would be good to take this into account.

It really depends :-) For the moment, we do not have much example of Model. Efl.Io shows that in the same code, their is place for batch insertion and solo insertion. Not sure how our code base is going to look once we have some network Model and so on.

Not necessarily, it depends on the internal of the code that is doing the insertion. Very often we do have Model temporary in memory that would be near where we insert. This is especially true if we are doing sorted insertion, as this require to compare models all the way to the point where we want to insert them.

Ideally we would want the ability to insert multiple items, but that seems only possible if Model are provided and not index (As index change every time an object is inserted).

This will be necessary to provide an Efl.SortedModel.