Recherche avancée

Sur d’autres sites (10337)

• To all Matomo plugin developers : Matomo 5 is coming, make your plugin compatible now

  5 mai 2023, par Matomo Core Team — Development

  We’re planning to release the first beta of Matomo 5 in a few weeks. For making it easy for Matomo users to be able to upgrade to this beta, it would be great to have as many plugins on the Marketplace as possible already updated and compatible with Matomo 5. Then many users would be able to upgrade to the first beta without any issues.

  Presumably, as you put your plugin on our Marketplace, you want people to use it. Making your plugin compatible with Matomo 5 helps ensure that people will be able to find and keep using your plugin. If your plugin is not compatible with Matomo 5, your plugin will be automatically deactivated in Matomo 5 instances. We’ll be happy to help you achieve compatibility should there be any issue.

  How do I upgrade my Matomo instance to Matomo 5 ?

  If you have installed your Matomo development environment through git, you can simply checkout the Matomo 5 branch “5.x-dev” and install its dependencies by executing these commands :

  • git checkout 5.x-dev
  • composer install

  Alternatively, you can also download the latest version directly from GitHub as a zip file and run composer install afterwards.

  How do I upgrade my plugin to Matomo 5 ?

  • We recommend you create a new branch for your plugin that supports Matomo 5. For example a branch named “5.x-dev“. This way you will be able to make changes to your plugin for Matomo 4 and Matomo 5 and release separate versions.
  • Check out our migration guide from Matomo 4 to Matomo 5 and make sure to review the list of all breaking changes.
  • Release a new version of your plugin in GitHub as usual.

  While there are some breaking changes in Matomo 5, most of our Platform APIs remain unchanged, and almost all changes are for rarely used APIs. Quite often, making your plugin compatible with Matomo 5 will just be a matter of adjusting the “plugin.json” file (as mentioned in the migration guide).

  You can find all developer documentation on our developer zone which has already been updated for Matomo 5.

  How do I know my plugin changes were released successfully ?

  If you have configured an email address within your “plugin.json” file, then you will receive a confirmation or an error email within a few minutes. Alternatively, you can also check out your plugin page on the Marketplace directly. If the plugin release was successful, you will see additional links below the download button showing which versions your plugin is compatible with.

  

  How can switch between Matomo 4 and Matomo 5 or downgrade to Matomo 4 ?

  To downgrade from Matomo 5 to Matomo 4 in your Matomo development environment :

  • check out the “4.x-dev” branch 
  • run “composer install” as usual

  When will the final Matomo 5 release be available ?

  We estimate the final stable Matomo 5.0.0 release will be released in approx. 2-3 months.

  What is new in Matomo 5 ?

  We don’t have a summary of the changes available just yet but you can see all closed issues within this release here.

  Any questions or need help ?

  If you have any questions, or experience any problems during the migration, don’t hesitate to get in touch with us. We’ll be happy to help get your plugin compatible and the update published. If you find any undocumented breaking change or find any step during the migration process not clear, please let us know as well.

  Thank you for contributing a plugin to the Marketplace and making Matomo better. We really appreciate your work !

• lavc/ffv1 : change FFV1SliceContext.plane into a RefStruct object

  11 juillet 2024, par Anton Khirnov

  lavc/ffv1 : change FFV1SliceContext.plane into a RefStruct object
  Frame threading in the FFV1 decoder works in a very unusual way - the
  
  state that needs to be propagated from the previous frame is not decoded
  
  pixels(¹), but each slice's entropy coder state after decoding the slice.
  For that purpose, the decoder's update_thread_context() callback stores
  
  a pointer to the previous frame thread's private data. Then, when
  
  decoding each slice, the frame thread uses the standard progress
  
  mechanism to wait for the corresponding slice in the previous frame to
  
  be completed, then copies the entropy coder state from the
  
  previously-stored pointer.
  This approach is highly dubious, as update_thread_context() should be
  
  the only point where frame-thread contexts come into direct contact.
  
  There are no guarantees that the stored pointer will be valid at all, or
  
  will contain any particular data after update_thread_context() finishes.
  More specifically, this code can break due to the fact that keyframes
  
  reset entropy coder state and thus do not need to wait for the previous
  
  frame. As an example, consider a decoder process with 2 frame threads -
  
  thread 0 with its context 0, and thread 1 with context 1 - decoding a
  
  previous frame P, current frame F, followed by a keyframe K. Then
  
  consider concurrent execution consistent with the following sequence of
  
  events :
  
  * thread 0 starts decoding P
  
  * thread 0 reads P's slice header, then calls
  
    ff_thread_finish_setup() allowing next frame thread to start
  
  * main thread calls update_thread_context() to transfer state from
  
    context 0 to context 1 ; context 1 stores a pointer to context 0's private
  
    data
  
  * thread 1 starts decoding F
  
  * thread 1 reads F's slice header, then calls
  
    ff_thread_finish_setup() allowing the next frame thread to start
  
    decoding
  
  * thread 0 finishes decoding P
  
  * thread 0 starts decoding K ; since K is a keyframe, it does not
  
    wait for F and reallocates the arrays holding entropy coder state
  
  * thread 0 finishes decoding K
  
  * thread 1 reads entropy coder state from its stored pointer to context
  
    0, however it finds state from K rather than from P
  This execution is currently prevented by special-casing FFV1 in the
  
  generic frame threading code, however that is supremely ugly. It also
  
  involves unnecessary copies of the state arrays, when in fact they can
  
  only be used by one thread at a time.
  This commit addresses these deficiencies by changing the array of
  
  PlaneContext (each of which contains the allocated state arrays)
  
  embedded in FFV1SliceContext into a RefStruct object. This object can
  
  then be propagated across frame threads in standard manner. Since the
  
  code structure guarantees only one thread accesses it at a time, no
  
  copies are necessary. It is also re-created for keyframes, solving the
  
  above issue cleanly.
  Special-casing of FFV1 in the generic frame threading code will be
  
  removed in a later commit.
  (¹) except in the case of a damaged slice, when previous frame's pixels
  
      are used directly
  

  • [DH] libavcodec/ffv1.c
  • [DH] libavcodec/ffv1.h
  • [DH] libavcodec/ffv1dec.c

• Different ways of embedding the Piwik tracking code for faster website performance

  18 avril 2017, par InnoCraft — Community, Development

  Many studies have shown that performance matters a lot. For each 100ms a websites takes longer to load, a business may lose about 0.1% to 1% in revenue. It also matters because Google judges page speed as a ranking factor for search results page. At InnoCraft, we help our clients optimizing their Piwik integration and recommend different ways of embedding the tracking code tailored to their needs. The best way to embed the tracking code depends on your website, what you want to achieve, and how important tracking is to you.

  This technical blog post mainly focuses on improving the time to load your website. This is an important metric as for example Google usually measures the time it took to load a page. Many businesses therefore want to get to the page load event as quickly as possible.

  The regular way of embedding the tracking code

  By default, Piwik is embedded in the header or footer of your website. This is a sensible default. While it is loaded asynchronously and deferred, it still does delay the onload event. Depending on the performance of your Piwik, how fast your website loads, how your website’s resources are embedded, and other factors you may want to consider alternatives. Three of them I will introduce below.

  Embedding the tracker after the load event

  To ensure that your website will always load even if the Piwik server is un-available, you may want to load the tracking code only after the website is loaded like this :

  var _paq = _paq || [];
  
  _paq.push(["trackPageView"]);
  
  _paq.push(["enableLinkTracking"]);
  
  
  
  function embedTrackingCode() {
  
     var u="https://your.piwik.domain/";
  
     _paq.push(["setTrackerUrl", u+"piwik.php"]);
  
     _paq.push(["setSiteId", "1"]);
  
  
  
     var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
  
     g.defer=true; g.async=true; g.src=u+"piwik.js"; s.parentNode.insertBefore(g,s);    
  
  }
  
  
  
  if (window.addEventListener) { 
  
      window.addEventListener("load", embedTrackingCode, false); 
  
  } else if (window.attachEvent) { 
  
      window.attachEvent("onload",embedTrackingCode); 
  
  } else {
  
      embedTrackingCode();
  
  }

  The downside is you won’t track all of your visitors because some will have already left your website by the time your website is fully loaded. Especially when you have a JavaScript-heavy website or when your website takes longer to load in general. To detect the load event correctly cross browser, you may want to use a library like jQuery.

  Delaying the tracking

  Another technique is to load the tracking with a little delay at the end of your website like this :

  setTimeout(function () {
  
      embedTrackingCode();
  
  }, 5);

  This time the tracking script will still track most of your visitors but does not slow down loading the rest of your website as much as it would do by default (at least perceived). In some cases, you will notice a performance improvement when looking at the “time to load” but it depends on your website.

  Not loading the JavaScript Tracker at all

  With Piwik you also have the option to not embed the tracking code into your websites at all and instead generate reports from the webserver logs using Piwik Log Analytics. This works very well but some data might not be available like the device resolution which can be only captured using JavaScript. On the bright side this solution also captures users with ad blockers or tracking blockers.

  Questions ?

  We invite you to test different ways to see what makes sense for you and how it affects your website performance as well as the perceived performance. If you have any questions, feel free to get in touch with us.

  Read on

  The last post in this series is Performance optimizations you can apply today to load the Piwik JavaScript tracker faster.