Recherche avancée

Sur d’autres sites (8888)

• Evolution #4148 : Augmenter la largeur de l’espace privé

  13 juin 2018, par tcharlss (*´_ゝ｀)

  Super nicod_, merci pour les remarques et le boulot :)

  Alors concernant la largeur, 1200px ce serait déjà beaucoup mieux.
  Mais pour ma part je pense que du 100% serait toujours la meilleur option. Au début ça fait un peu bizarre je le concède, mais on s’y fait vite et c’est dur de revenir sur une largeur fixe après. Pour les tableaux / listes d’objets par exemple ça devient vite indispensable. Le menu ne me pose pas de problème non plus : on comprend que les items sont alignés à gauche.

  Il y a bien certains contenus qui doivent être limité en largeur pour avoir 80 caractères par ligne c’est vrai, mais il s’agit de quelques blocs à identifier, et ça reste valable quelque soit la largeur globale de l’interface.
  Pour l’instant je ne vois que 2 blocs concernés : le #wysiwyg et les formulaires d’édition.
  Donc mon constat c’est : à partir du moment où on limite la largeur de certains blocs qui contiennent du texte afin que ça reste lisible, pourquoi limiter arbitrairement la largeur globale de l’interface ?
  Dans le plugin privé fluide, seul le #wysiwyg est ciblé pour l’instant. Attention il reste aussi des petits problèmes à régler dans certains cas, cf. capture d’écran.

  Pour comparaison, avec RastaPopoulos on avait installé une floppée de CMS pour étudier leurs interfaces au moment où on s’intéressait au sujet, et ils ont tous une largeur 100%.
  Je ne dis pas qu’il faut suivre bêtement ce que font les autres, mais ça donne des exemples concrets de choix de layouts qui fonctionnent.

  Sur la question de rendre cette largeur configurable, je ne suis pas très chaud. C’est exactement pour ça que j’avais fait le plugin privé fluide dans mon coin alors qu’il existe déjà le plugin d’Ybbet : je pense que l’interface doit être d’office adaptée à tous les écrans, sans rien à configurer. Aucune envie d’avoir à configurer ça sur chaque nouvelle instance de SPIP qu’on déploie :p

  Du coup on écrivant tout ça, je verrais finalement la chose comme ça :

  • Largeur globale 100%
  • Supprimer carrément la préférence utilisateur « taille de l’écran »
  • Jusqu’à 1200px : 2 colonnes (#navigation + #extra | #contenu)
  • Au-delà : 3 colonnes (#navigation | #contenu | #extra)

  Du coup en écran large on aurait toujours 3 colonnes et ça équilibre un peu plus.
  Et plutôt que du flex, je pense qu’on pourrait partir directement sur du css grid, avec un bête fallback en float pour les vieux navigateurs.
  Parceque du coup je ne vois pas comment mettre la colonne #extra soit en dessous de #navigation, soit à droite de #contenu juste avec du flex.

• Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know

  5 juin 2018, par Matomo Core Team

  In Matomo 3.5.0 we added a new feature to improve the location detection (country, region, city) of your visitors. Especially when it comes to IPv6 addresses, you will see less “Unknown” locations and more accurate results in general. This feature is now enabled for all new installations but needs to be manually enabled for existing Matomo self-hosted users.

  

  Why is the Matomo plugin not enabled for existing users ?

  When you enable the GeoIP2 plugin, a database update will need to be executed on two datatable tables (“log_visit” and “log_conversion”) which stores some of the raw data. Please be aware that this update could take several hours depending on the size of your database.

  If you store many visits in your database, it is recommended to execute the update through the command line by executing the command ./console core:update to avoid the update from timing out. You may also have to put your Matomo into maintenance mode during this time and replay the missed traffic from logs afterwards as explained in the FAQ article.

  GeoIP2 may slow down your tracking

  In the past we have seen that a few Matomo databases with high traffic volumes struggle to handle all the tracking requests after enabling GeoIP2. The reason for this is the location database now contains many more entries because it has to store all the IPv6 addresses and the database itself has a different format. Hence, the location lookup takes longer.

  It is hard to say how much slower the location lookup gets, but we found GeoIP2-PHP is about 20 times slower than GeoIP1-PHP. On a fast CPU the lookup time for an IP with GeoIP2 takes about 1ms, but can also take much longer depending on the server.

  Making location lookups fast again

  There is a PHP extension available that makes lookups very fast, even faster than the old GeoIP1-PHP provider. If you can install additional PHP extensions on your server and have a high traffic website, you may want to install the GeoIP2 extension.

  There is also an Nginx module and an Apache module. Unfortunately, we don’t have any performance metrics for these providers.

  How do I activate the GeoIP2 location provider ?

  As a Super User, log in to your Matomo and go to “Administration => Plugins”. There you can activate the “GeoIP2” plugin. As mentioned, this will trigger a database update which can take a while and you may want to perform this update through the command line.

  Now you can go to “Administration => Geolocation”. Here you will first need to install the GeoIP2 databases at the bottom of the page before you can activate the GeoIP2-PHP provider. To activate any of the other GeoIP2 providers, you will need to install the required modules.

  You will be able to check if the detection works on the right next to location provider. Once you selected one of the available providers, you’re all good to go.

  The post Thinking about switching to GeoIP2 for better location detection ? Here’s what you should know appeared first on Analytics Platform - Matomo.

• Surfaceview/TextureView for subtitles alpha does not work

  27 mai 2018, par user654628

  Goal : trying to build video player with subtitles for android. Video can be low resolution but the subtitles should be resolution of phone (such that if video is 720p, the subtitles should render to screen size say 1080p).

  Issue : Render on Textureview or Surfaceview is not see through where you could get it to blend with the background views. I am using FFMPEG to render a frame at say 720p but phone device is 1080p. I need to display subtitles that are different resolution than the subtitles resolution so pixel blending is difficult.

  I first tried to scale the frame (AVFrame) with sws_convert but each frame took 80ms so that is not an option (since it is running software).

  Then I tried two surface views, one for the video and one for subtitles where video would be 720p and subtitles SurfaceView is 1080p, then the video scales up to the phone size. The issue here is that the subtitles are not translucent. Black opacity 0 would be transparent but white with alpha 0 is still white. Why is this ?

  //Code from Java, the view that extends FrameLayout
  
  public VideoView(@NonNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
  
      super(context, attrs, defStyleAttr);
  
      mVideoSurface = new SurfaceView(context);
  
      mSubtitlesSurface = new SurfaceView(context);
  
      addView(mVideoSurface);
  
      addView(mSubtitlesSurface);
  
      mVideoSurface.getHolder().addCallback(mSurfaceCallback);
  
      mSubtitlesSurface.getHolder().addCallback(mSurfaceCallback);
  
      mSubtitlesSurface.setZOrderMediaOverlay(true);
  
      mSubtitlesSurface.getHolder().setFormat(PixelFormat.TRANSLUCENT);
  
      //etc
  
  }

  Eventually I tried as a test to render a square to the subtitle surface view (C++)

  // Render the video frame, now render the subtitle frame
  
  ANativeWindow_Buffer buffer;
  
  ANativeWindow_setBuffersGeometry(subWindow, width, height, WINDOW_FORMAT_RGBA_8888);
  
  if ((ret = ANativeWindow_lock(subWindow, &buffer, NULL)) < 0) {
  
      return ret;
  
  }
  
  for (int j = height/2; j < height/2 + 100; j++) {
  
      for (int i = width/2; i < width/2 + 100; i++) {
  
          uint8_t * d =  (uint8_t*)buffer.bits + j * (buffer.stride * 4) + i * 4;
  
          d[0] = 0xff;
  
          d[1] = 0xff;
  
          d[2] = 0xFF;
  
          d[3] = 0;           /* alpha */
  
  
  
      }
  
  }
  
  ANativeWindow_unlockAndPost(subWindow);

  So above code should render a white square in the image with 0 alpha (so should be invisible), but it is shown. If I change it to yellow with alpha 0 it will be visible but not the correct color. If I change to white with 1 alpha, it is white and opaque. If I use black with alpha 0xCC, it is invisible, only if alpha is 0xFF then it is visible as black. Seems to have no translucency even though I added it to the SurfaceHolder. Why is it like this ? I can add more code if needed.

  Is my only option to do what I want to render frame as a texture in OpenGL and (GLSurfaceView), resize the image to phone resolution and blend the alpha subtitles onto the frame as a texture ?

  Thanks in advance.