1. 01 Mar, 2005 3 commits
  2. 28 Feb, 2005 6 commits
  3. 27 Feb, 2005 6 commits
    • Felix Paul Kühne's avatar
      * removed prefs_widgets.h, prefs_widgets.m, playlistinfo.h, playlistinfo.m,... · f6077fea
      Felix Paul Kühne authored
      * removed prefs_widgets.h, prefs_widgets.m, playlistinfo.h, playlistinfo.m, equalizer.m, equalizer.h, voutgl.m, voutqt.m from the build target, so they don't get copied in the Resources-folder of the binary bundle
    • Steve Lhomme's avatar
    • Mark Moriarty's avatar
    • Mark Moriarty's avatar
    • Mark Moriarty's avatar
      freetype and rc extensions. i_font_color and i_font_opacity added to... · e1381cf7
      Mark Moriarty authored
      freetype and rc extensions.  i_font_color and i_font_opacity added to subpictures, allowing per-object control (defaulting to freetype).  marq and time updated to allow font color and opacity control.  rc update to allow OTF control of all marq and time options.
    • Andre Pang's avatar
      * modules/macosx/{vout,voutqt}.m: The Mac OS X Mozilla plugin lives again! · ff146815
      Andre Pang authored
      Some details:
      * This was mostly taken verbatim from revision:5717 (before the vout
        Mozilla support was removed), though it's been edited pretty thoroughly,
        and is now much more commented.
      * The "normal" vout display should be completely unaffected, since the
        plugin-relevant code paths are only taken when p_vout->p_sys->b_embedded is
        set to VLC_TRUE.  (I've tested the normal VLC.app, and it seems fine.)
      * There are still some problems with the plugin when the Mozilla window is
        resized a lot.  I suspect this is due to threading issues with
        QuickDraw, but I don't know enough about QuickDraw to be sure.  Help
        with this would be very welcome.
      * The original patch in revision:5717 optimised the plugin display
        slightly, by using a mask (clipping region) so that QuickDraw only
        updated the plugin's area of the dirty region.  I elected not to use
        a mask, since I thought the extra code complexity (i.e. lots more if()
        branches) isn't worth the incremental speedup.  (If, in fact, there was
        a speedup at all -- the extra overhead induced by calculating the
        intersection of the dirty region with the mask may have offset any
        benefits: only benchmarks will tell ...)
  4. 26 Feb, 2005 2 commits
  5. 25 Feb, 2005 2 commits
  6. 24 Feb, 2005 5 commits
  7. 23 Feb, 2005 16 commits