I am French so I love cheese, baguette and croissant, but not quite wine. I have been kidnapped a year or so by Samsung ninja team in Korea. I am also know as The borker will see if that survive our move to git !
User Details
- User Since
- Jan 25 2013, 3:13 AM (523 w, 4 d)
- Roles
- Administrator
- Availability
- Available
May 28 2021
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.
Apr 20 2021
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.
Apr 19 2021
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.
Mar 30 2021
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.
Nov 6 2020
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.
Sep 18 2020
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?
Aug 17 2020
Aug 5 2020
Jul 31 2020
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?
Jul 2 2020
Jun 29 2020
Jun 17 2020
As said in a previous PR, would be nice to refactor this.
Jun 8 2020
May 26 2020
May 15 2020
Indeed, I always hide my tab.
Jan 31 2020
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.
Jan 30 2020
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>?
Jan 29 2020
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 :-)
Jan 28 2020
As long as you do not replace layout factory, but add a new generic factory which layout inherit from, yes.
Jan 24 2020
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.