Vô tình dùng Blender VSE

 (aras-p.info)
1 điểm bởi GN⁺ 2024-02-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Aras thậm chí không biết Blender có Video Sequence Editor (VSE), nhưng sau khi ghé thăm Blender HQ, trong khoảng hai tháng làm bán thời gian anh đã đóng góp các cải tiến về hiệu năng và chất lượng cho Blender 4.1
  • Thay đổi nổi bật nhất là độ phản hồi của timeline: trong dự án Sprite Fright với khoảng 3.000 strip hiển thị, UI khi cuộn và pan đã cải thiện từ khoảng 15fps lên hơn 60fps
  • Đa luồng, SIMD và đơn giản hóa toán học được áp dụng cho chuyển đổi RGB↔YUV dựa trên ffmpeg, resampling âm thanh Audaspace, biến đổi/lọc ảnh và xử lý hiệu ứng VSE
  • Trên ba bộ dữ liệu của Blender Studio, thời gian render cuối cùng phim bằng VSE trên PC của tác giả nhanh hơn khoảng 2 lần; render Sprite Fright giảm từ gần 13 phút xuống 7 phút
  • Tổng cộng 37 pull request đã được review và merge; các thay đổi hiện đã vào Blender 4.1, còn công việc VSE tiếp theo dự kiến sẽ tiếp tục từ Blender 4.2

Cơ duyên đóng góp cho Blender VSE

  • Aras đến Amsterdam để dự Unite 2023 của Unity và trong thời gian rảnh đã ghé thăm Blender HQ
  • Tại đó, Francesco và Sergey hỏi anh có muốn đóng góp cho VSE không, và sau đó anh bắt đầu đụng tới Video Sequence Editor của Blender
  • Dù không rành về biên tập video, timeline, sequencer, color grading, ffmpeg hay audio mixing, anh bắt đầu từ phần tối ưu hiệu năng, vốn ít gây tranh cãi hơn
  • Sau khoảng hai tháng làm bán thời gian, một nhóm cải tiến để đưa vào Blender 4.1 đã hình thành
    • Blender 4.1 đã vào beta và có thể tải từ các bản daily builds thông thường

Vẽ timeline và độ phản hồi UI

  • Timeline của VSE là vùng ở phía dưới màn hình; khi zoom out toàn bộ dự án Sprite Fright edit, có thể thấy khoảng 3.000 strip cùng lúc
  • Trước đây, chỉ cần cuộn hoặc pan trên timeline này thì tốc độ cập nhật UI chỉ quanh mức 15fps
  • Sau thay đổi, nó chạy ở mức hơn 60fps
  • Nút thắt nằm ở cấu trúc gửi draw call của graphics API theo từng cặp tam giác; trong profiler Superluminal, phần lớn thời gian được dùng trong các hàm “bắt đầu vẽ một quad” và “kết thúc vẽ một quad”
  • Trong quá trình này, anh cũng sửa hành vi bất thường của hiển thị audio waveform và tinh chỉnh UI; hiển thị waveform được bật mặc định

Cải thiện chất lượng và tốc độ hiển thị scope

  • VSE cung cấp các tùy chọn hiển thị scope phổ biến như histogram ảnh, waveform và vectorscope
  • Histogram từng được vẽ bằng hình ảnh bị pixel hóa với độ bão hòa màu rất mạnh, nhưng nay được hiển thị bằng polygon và grid mượt hơn, với độ bão hòa thấp hơn
  • Tùy chọn parade của Waveform có vấn đề bị bão hòa quá nhanh, và sau khi áp dụng đa luồng đã nhanh hơn 15 lần
  • Hình lục giác màu ở viền ngoài của Vectorscope bị pixel hóa nặng; anh đã sao chép và áp dụng design đã cập nhật của vectorscope trong image editor
  • Tùy chọn zebra stripes, dùng để “hiển thị vùng quá sáng”, cũng nhanh hơn 2–3 lần
  • Anh cũng nói thêm rằng về lâu dài, tất cả scope và scope của image editor nên được xử lý bằng GPU compute shader

Tối ưu chuyển đổi RGB↔YUV của ffmpeg

  • Blender chủ yếu dùng thư viện ffmpeg để đọc và ghi audio/video
  • Bên trong Blender, họ dùng các thư viện mã như libavcodec, chứ không phải công cụ dòng lệnh ffmpeg; libswscale phụ trách chuyển đổi RGB↔YUV cho frame phim
  • libswscale hỗ trợ chuyển đổi đa luồng, nhưng nếu chỉ dùng sws_getContext() và sws_scale() thì nó chạy hoàn toàn đơn luồng
  • Để dùng đa luồng, cần đặt tham số "threads" ở thời điểm khởi tạo, nên phải dùng trực tiếp sws_alloc_context(), av_opt_set_int(), sws_init_context()
  • Ngoài ra, vì sws_scale() không tự đa luồng ở bên trong, cần dùng sws_scale_frame(), và trong quá trình này cũng lộ ra vấn đề về cách tạo AVFrame
  • Kết quả là chuyển đổi RGB→YUV khi ghi file phim nhanh hơn đáng kể
  • Khi đọc file phim, Blender cũng dùng chuyển đổi YUV→RGB đa luồng và gộp vertical flip vào cùng tác vụ

Resampling âm thanh

  • Khi render video trong VSE, anh nhận thấy gần một nửa thời gian “tạo frame video hoặc audio” được dùng bên trong thư viện âm thanh Audaspace mà Blender sử dụng
  • Nút thắt không phải audio encoding, mà là mixing trước khi encode; phần lớn xảy ra khi các audio strip như 44,1kHz được trộn vào phim 48kHz
  • Audaspace có hai chế độ resampling
  • Chất lượng resampler được so sánh bằng cách resample một âm tổng hợp có một tần số tăng dần rồi xem spectrogram
    • Mục tiêu là kết quả có càng ít tần số bổ sung càng tốt, giống thiết lập “best” của Audacity
  • Resampling preview của Audaspace tính toán nhanh nhưng tạo ra nhiều tần số bổ sung, còn resampling khi rendering có chất lượng spectrogram tốt
  • Anh đã thêm mức chất lượng resampling medium mới vào Audaspace; theo tác giả, nó cho kết quả gần như giống nhau nhưng tính toán nhanh hơn khoảng 3 lần
  • Blender sẽ dùng thiết lập medium này khi render
    • Trên PC Windows Ryzen 5950X, render 2.000 frame Sprite Fright giảm từ 92 giây xuống 73 giây
    • PR liên quan: #116059

Biến đổi và lọc ảnh

  • Trong VSE, các strip tạo kết quả hình ảnh như ảnh, phim, văn bản và scene có thể áp dụng vị trí, xoay, scale và crop
  • Các phép biến đổi này hoạt động bằng cách biến đổi ảnh do strip tạo ra thành một ảnh mới, và trước đây cũng đã được xử lý đa luồng trên CPU
  • Lý do xử lý trên CPU thay vì GPU là vì hiện chưa có triển khai GPU, và CPU fallback hiện vẫn cần thiết cho trường hợp người dùng muốn render trên render farm không có GPU

  • Sửa lỗi lệch half-pixel

    • Code cũ có nhiều lỗi off by half a pixel; trong nhiều trường hợp chúng triệt tiêu nhau hoặc không nhìn thấy, nhưng ở một số tình huống cụ thể thì lộ ra
    • Khi phóng to ảnh nhỏ lên 16 lần, bộ lọc Bilinear làm ảnh bị dịch đi nửa pixel so với pixel gốc, và còn có hiện tượng màu nền magenta chen vào
    • Ngược lại, khi thu nhỏ ảnh đúng 2 lần, bộ lọc Bilinear lại không lọc gì cả
    • Các lỗi “off by something” của Bilinear và các bộ lọc khác đã được sửa
    • PR liên quan: #116628

  • Xử lý viền trong suốt của Bilinear

    • Trước Blender 4.0, VSE có ba tùy chọn bộ lọc Nearest, Bilinear, Subsampled3x3; trong đó chỉ Bilinear thêm độ trong suốt rộng nửa texel gốc quanh ảnh kết quả
    • Hành vi này dễ thấy khi phóng to media, và không còn ai nhớ vì sao lại có khác biệt này
    • Anh đã loại bỏ hành vi “blend với độ trong suốt” khỏi code bộ lọc Bilinear của VSE
    • Tuy nhiên, khi chỉ áp dụng xoay, cách xử lý độ trong suốt cũ tạo ra một dạng anti-aliasing ở edge, nên thay vào đó anh áp dụng transparency anti-aliasing cho edge pixel của ảnh đích
    • PR liên quan: #117717

  • Bộ lọc Cubic, Box, Auto

    • Transform strip thông thường của VSE không có tùy chọn bộ lọc cubic; nó chỉ tồn tại trong strip Transform Effect đặc biệt
    • Trong Blender, “Bicubic” thực ra nghĩa là bộ lọc Cubic B-Spline, tương đương với hệ số B=1, C=0 của Mitchell-Netravali filter
    • Tác giả tóm tắt lựa chọn này là “không ringing nhưng blur nhiều”
    • VSE được thêm hai loại tùy chọn cubic filtering
    • PR liên quan: #117100, #117517
    • Bộ lọc “Subsampled 3x3” của Blender 3.5 thực ra là box filter được hard-code kích thước 3x3, và bắt đầu hỏng khi thu nhỏ theo tỷ lệ không phải 3x3
    • Bộ lọc này được thay bằng Box filter có điều chỉnh, thay vì 3x3 cố định
    • PR liên quan: #117584
    • Vì có thêm nhiều bộ lọc mà người dùng phải chọn, Auto filter option được thêm làm mặc định cho strip VSE
    • PR liên quan: #117853
    • Nếu không có scale/xoay thì Nearest
    • Nếu phóng to hơn 2 lần thì Cubic Mitchell
    • Nếu thu nhỏ hơn 2 lần thì Box
    • Các trường hợp còn lại thì Bilinear

  • Cải thiện hiệu năng lọc

    • Quá trình lọc ảnh cũng nhanh hơn
    • Loại bỏ virtual function trong vòng lặp bên trong, áp dụng một phần SIMD cho lọc Bilinear: #115653
    • Đơn giản hóa lọc Cubic và thêm SIMD: #117100
    • Đơn giản hóa toán học của Box filter: #117125
    • Sửa lỗi tối ưu bỏ qua các mục nằm dưới một solid image phủ toàn màn hình không hoạt động khi có scale: #117786
    • Trên PC của tác giả, với một dự án 3840x2160 có một ảnh 1920x1080 được phóng to 2 lần và dùng lọc Bilinear, toàn bộ việc vẽ sequencer preview giảm từ 36,8ms xuống 15,9ms
    • Anh cũng cung cấp một trang tương tác để so sánh các bộ lọc upsample: aras-p.info/img/misc/upsample_filter_comp_2024

Tối ưu hiệu ứng VSE

  • Các bộ dữ liệu phim thực tế của Blender Studio không dùng nhiều effect, nhưng anh cũng tối ưu các VSE effect, chủ yếu dựa trên những phần thấy được trong code
  • Phần lớn thay đổi là áp dụng đa luồng
    • Glow effect: áp dụng đa luồng, nhanh hơn 6–10 lần #115818
    • Wipe effect: áp dụng đa luồng, đơn giản hóa lượng tính toán hàm lượng giác quá mức của Clock wipe, nhanh hơn 6–20 lần #115837
    • Gamma Cross effect: thay đổi cách dùng table và interpolation phức tạp vốn chỉ để tránh một lệnh gọi căn bậc hai, nhanh hơn 4 lần #115801
    • Gaussian Blur effect: tránh tính toán trùng lặp, nhanh hơn 1,5 lần #116089

Thay đổi thời gian render cuối cùng

  • Dựa trên ba bộ dữ liệu nhận từ Blender Studio, thời gian render cuối cùng phim bằng VSE trên PC của tác giả nhanh hơn khoảng 2 lần
  • Render Sprite Fright edit giảm từ gần 13 phút xuống 7 phút
  • Tác giả mong muốn có thêm cải thiện tốc độ, và diễn đạt đại ý rằng “nếu có thêm ba lần cải thiện 2x nữa thì khá tốt”

Cách làm việc và bước tiếp theo

  • Ngoài các thay đổi người dùng nhìn thấy, còn có các pull request để thêm test, refactor và dọn dẹp; tổng cộng 37 pull request đã hoàn tất, được review và merge
  • Tác giả đánh giá rằng mức công việc này có lẽ khó thực hiện trong “công việc thực sự”
    • Anh nói nếu ở Unity giai đoạn 2015–2022, với cùng lượng thời gian có lẽ chỉ làm được khoảng 30% số việc trên, thậm chí có thể ít hơn
    • Anh nói thêm rằng với Unity “cổ đại” khoảng năm 2010 thì có lẽ đã có thể làm được
  • Anh cho rằng khi các yếu tố như quy mô công ty, quy trình, kỳ vọng, giao tiếp và chính trị đan xen, trong môi trường công ty trả lương, cùng một công việc có thể chậm hơn hoặc bị hủy giữa chừng
  • Anh hy vọng Blender sẽ không đi tới quy mô, độ phức tạp và workflow nơi quy trình làm mọi người nản lòng và chậm lại thay vì giúp họ
  • Vì Blender 4.1 đã vào beta, về mặt tính năng nó đã ở trạng thái hoàn tất; các thay đổi VSE liên quan đến 4.1 hiện đã vào trạng thái release notes
  • Công việc cho Blender 4.2 đang bắt đầu, và anh dự định sẽ tiếp tục đụng tới VSE mà không có kế hoạch rõ ràng

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-02-09
Ý kiến trên Hacker News

  • Nếu đây là “công việc thực sự” thì có lẽ đã không làm được việc như vậy
    Nếu có điều gì đó không suôn sẻ trong sự nghiệp của tôi, thì đó là sự tách biệt kiểu này: với một dự án không lương tự mình giải những bài toán hoàn toàn độc đáo, tôi làm được trong hai tháng nhiều hơn bình thường trong hai năm; còn với các dự án được trả tiền, kết quả nhìn chung chỉ ở mức trung bình
    Tôi đã cố gắng rất nhiều nhưng vẫn không tìm được điểm cân bằng, và năm ngoái khi có khả năng được trả tiền cho việc trước đó làm miễn phí, rốt cuộc tôi lại hoàn toàn không thể động vào nó

    • Bạn không đơn độc đâu. Tôi đã trải qua chuyện tương tự suốt đời, và vì thế trở nên hoài nghi với mọi điều người ta nói về động lực, chẳng hạn ý tưởng rằng chỉ lợi nhuận và tiền lương mới khiến công việc được hoàn thành
      Rồi tôi tiếp cận lý thuyết tha hóa của Marx và mọi thứ bắt đầu hợp lý hơn nhiều. Ông xuất phát từ quan sát rằng lao động là hoạt động mà người khỏe mạnh thường làm, nhưng cho rằng không nên nhầm lẫn điều đó với việc làm cho người khác và bị tha hóa khỏi sản phẩm lao động của chính mình
      https://en.m.wikipedia.org/wiki/Marx's_theory_of_alienation
    • Những việc tuyệt vời hoặc thú vị nhất tôi từng làm cho đến nay đều không phải là việc được trả tiền
    • Quản lý dự án giết chết tất cả những kiểu công việc như vậy
      Một số nơi có hệ thống tốt, dành ra khoảng đệm 1–2 tuần để có thể làm bất cứ thứ gì, và điều đó giúp giảm nhẹ vấn đề này
    • Những việc khiến tôi thấy đáng làm nhất và có tác động nhất đều là những việc hầu như không được trả tiền hoặc hoàn toàn không được trả. Giờ nó cảm giác như điều khó tránh, và khiến công việc phần mềm hơi u ám
    • Đây là một hiện tượng khá thú vị, và tôi cho rằng phần lớn đến từ quy mô đội nhóm và nhu cầu phải kiếm tiền
      Với dự án đam mê, vì không nhận tiền nên kỳ vọng thấp, không có nghĩa vụ phải làm gì, và trên thực tế có thể tự do làm điều mình muốn. Vì vậy người ta sẽ chọn những việc vừa thú vị với bản thân vừa có tác động, chẳng hạn khám phá công nghệ hay công cụ mới mà mình quan tâm
      Ngay khi tiền bước vào, kỳ vọng của người trả tiền cũng xuất hiện, và những thử nghiệm mới lạ, xa lạ trở nên khó hơn vì khả năng thất bại lớn
      Cuối cùng, khi có tiền liên quan, tôi nghĩ mọi người sẽ tránh các hướng có rủi ro cao dù tiềm năng có giải pháp tốt hơn, và ưu tiên kết quả có thể dự đoán

  • Thực sự ấn tượng, và cũng rõ ràng là tác giả bài gốc không phải chỉ đơn giản bước từ ngoài đường vào Blender HQ. Kinh nghiệm lâu năm ở Unity hẳn đã giúp ích khá nhiều trong việc hiểu lĩnh vực này
    Tôi đặc biệt thích thay đổi này [1]. Trong lúc tối ưu hóa bước xử lý ảnh, tác giả đã loại bỏ rất nhiều phần “tối ưu hóa” dựa trên bảng và chỉ thay bằng tính toán dấu phẩy động, vậy mà trên máy của tác giả lại nhanh hơn khoảng 4 lần. Tuyệt vời
    [1]: https://projects.blender.org/blender/blender/pulls/115801/fi...

    • Không chỉ vậy, nhìn diff thì họ đã thay 100–150 dòng code bằng 3 dòng. Pull request kiểu này chắc chỉ có thể tạo ra trong mơ
    • Đây là tối ưu hóa tốt, nhưng tôi tự hỏi liệu return c * c; có thật sự là một xấp xỉ tốt cho gamma sRGB không

  • Mấy năm qua, điều tôi thích nhất là việc Aras bất ngờ nhảy vào nhiều dự án đồ họa mã nguồn mở, tạo ra các cải thiện và tăng tốc khổng lồ, rồi lại chuyển sang một dự án đồ họa ngẫu nhiên khác và lặp lại điều tương tự

  • Tôi cũng muốn làm việc kiểu này với trình phát nhạc MusicBee mà tôi đang dùng
    Giá mà nó là mã nguồn mở. Người tạo ra nó giờ gần như không còn động vào nữa, nó hoàn toàn miễn phí và luôn như vậy, nên tôi không hiểu vì sao lại không phải mã nguồn mở
    Có quá nhiều vấn đề nhỏ gây khó chịu, những phần lặt vặt bị hỏng, chậm hoặc kỳ quặc, đến mức tôi rất muốn sửa chúng trong thời gian rảnh
    Còn giờ mà chuyển sang thứ khác như FooBar thì quá nhiều việc. Tôi cũng đã thử HQPlayer, nhưng UI/UX quá tệ nên không thể chuyển sang được

    • Như Steven đã nói nhiều lần từ năm 2013, trong tương lai gần không có kế hoạch mở mã nguồn MusicBee
      Ông nói rằng công bố mã nguồn là một trong các lựa chọn có thể cân nhắc khi không còn muốn tiếp tục dự án, nhưng đây là dự án sở thích làm vì thích lập trình, và sẽ tuyệt đối không vận hành theo cách chuyên nghiệp
      Ông đã dành đủ thời gian quản lý con người ở công việc chính nên không muốn làm thêm việc đó ở đây; ông cũng nói rằng những ai lo kiểu “nếu bị xe buýt tông thì sao” thì nên dùng ứng dụng khác
      https://web.archive.org/web/20170721042120/https://getmusicb...
    • Vì ngay khoảnh khắc biến một dự án phần mềm thành mã nguồn mở, nó trở thành dự án quản lý con người
    • Để viết code cho một dự án mã nguồn mở, mức độ hoàn thiện cần có cao hơn nhiều so với mọi người nghĩ. Nó nhiều việc hơn rất nhiều so với chỉ làm cho chương trình chạy tốt
    • Có phương án thay thế: viết lại toàn bộ dưới dạng mã nguồn mở
    • MusicBee là phần mềm duy nhất tôi vẫn nhớ sau khi thôi dùng Windows
      Nếu nó còn được bảo trì, tôi đã cân nhắc chạy bằng Wine, nhưng giờ tôi đã từ bỏ luôn khái niệm trình quản lý nhạc và chỉ phát album mình nghe bằng mpv. Và tôi luôn nghe theo album. Playlist thì xin miễn

  • Tôi đã dùng Blender VSE cho mọi việc dựng video từ năm 2020, và thật sự rất vui khi thấy nó được cải thiện
    Xét về độ ổn định và bộ tính năng, tôi đã xem nó là trình dựng video tốt nhất trên Linux. Việc có thể dùng toàn bộ công cụ animation sẵn có của Blender cũng là một lợi thế

  • VSE thật sự cần rất nhiều tình yêu. Tôi từng muốn dùng toàn bộ công cụ mã nguồn mở cho podcast, nhưng khi render một chuỗi mp4 có chroma key trong Blender thì video 1,5 giờ mất 10 giờ
    Cuối cùng tôi chuyển sang bản miễn phí của DaVinci Resolve

    • Blender VSE hiện không có tăng tốc GPU cho render video, nên CPU phải xử lý toàn bộ công việc
      Ngoài ra, ngay cả khi không cần mã hóa lại, nó cũng không thể bỏ qua như DaVinci Resolve mà vẫn render từng frame một. Nếu phần này được cải thiện, hiệu năng và hiệu quả của Blender sẽ được giúp ích rất nhiều
    • Render đa luồng của Blender có vấn đề là không mở rộng tốt cho tác vụ VSE. Nó tập trung vào việc chia nhỏ từng frame nên không tận dụng tốt nhiều core
      Trước đây tôi từng thử một plugin [1] khởi chạy nhiều tác vụ render ở các vị trí khác nhau trên timeline dưới dạng các process riêng, và có thể làm render nhanh hơn rất nhiều
      Giờ thì cả trên Linux tôi cũng đã chuyển sang Resolve, vì tôi dùng camera Blackmagic nên bên đó phù hợp hơn
      [1] https://github.com/AkBKukU/blenderSubprocessRender
    • Tôi từng dùng VSE trong một dự án. Dù khá đau khổ nhưng vẫn tạo được sản phẩm, và khi đó nó chắc chắn là trình biên tập video phần mềm miễn phí tốt nhất
      Hiện tôi đang làm phiên bản mới bằng Final Cut Pro

  • Có lẽ khá khó để làm bất kỳ phần nào của chương trình Blender 3D nhanh hơn. Nó đã là ứng dụng 3D khởi động nhanh nhất một cách áp đảo, và GUI cũng phản hồi nhanh nhất
    Houdini đứng thứ hai, nhưng không phải là một vị trí thứ hai sát nút

    • Bất ngờ là vẫn còn nhiều quả thấp dễ hái
      Vài năm trước, khi động vào mã của bộ tạo ‘blobby’, tôi từng thêm đa luồng và khiến nó chậm hơn nhiều. Khi vượt qua được overhead của đa luồng thì nó có nhanh hơn, nhưng theo trí nhớ thì không rơi vào các trường hợp sử dụng thông thường, nên tôi đã bỏ cuộc. Chắc chắn tôi cũng đã mắc vài sai lầm
    • Tôi đã xem một phần mã và nghĩ vẫn còn nhiều chỗ có thể cải thiện. Như bài viết nói, có nhiều đoạn mã đáng ngạc nhiên là cách tiếp cận nhân danh tối ưu hóa thì rất phức tạp, nhưng thực tế cũng có khả năng làm chậm đi
      Ví dụ texture painting kiểu như mỗi pixel phải qua khoảng 3 lần tham chiếu gián tiếp con trỏ, và trên PC của tôi cũng khá giật
    • Các công cụ animation còn rất nhiều dư địa cải thiện, và có vẻ thực tế đang được triển khai. Việc chuyển sang Vulkan trông cũng sẽ giúp ích lớn

  • Bài viết nói “Bạn có biết Blender có một bộ công cụ biên tập video không? Tôi cũng không biết :)”, nhưng tôi nghĩ hầu hết những người làm animation bằng Blender đều biết
    Vì đó là cách cơ bản để biến các frame đã render thành file video

    • Có thể render frame trực tiếp thành file video (tùy chọn ffmpeg), và người mới hoặc người dùng nhẹ có lẽ làm vậy khá nhiều
      Cũng có thể dùng compositor để biến chuỗi frame đã render trước thành file video
      Tuy nhiên đa số có lẽ thích biên tập video trong chương trình khác như Resolve, còn VSE nằm trong phạm vi hẹp kiểu “cần cắt ghép cơ bản nhưng không cần biến đổi, tiêu đề, hiệu ứng”, nên cảm giác không được dùng nhiều
      Mong có ai đó tiếp tục cải thiện biến đổi và hiệu ứng, và một ngày nào đó thêm cả biên tập 3 điểm

  • À, hóa ra là Aras. Anh ấy rất giỏi. Tôi nhớ hình như tên đầy đủ của anh ấy là Aras rất-đỉnh
    Anh ấy xuất sắc trong lập trình đồ họa và có vẻ cũng có dòng chảy tập trung tốt khi code
    Bài viết dễ đọc và thú vị. Cảm giác như đang nghe một người nói chuyện. Cả những câu như “However!” ở giữa cũng vậy
    Tôi cũng đồng cảm với đoạn cuối nói rằng trong một công ty thông thường, nếu bị đè nặng bởi kỳ vọng về văn hóa và quy trình tiêu chuẩn thì năng suất chỉ còn 30%. Chi phí của việc buộc nhân viên vào “công việc của họ” thực sự bao gồm một mức giảm năng suất khổng lồ
    Tôi hy vọng khi tiếp tục thấy những trường hợp như thế này, giới kỹ thuật sẽ học cách tổ chức con người và hoạt động tốt hơn, tin vào những bài học đó, và bắt đầu tích hợp năng suất cao/mức độ nhập tâm cao vào cách tổ chức thực tế
    Như bài viết ngụ ý, làm vậy có thể khiến việc làm trong ngành công nghệ thú vị hơn. Nó thậm chí có thể gần thú vị như việc chơi đùa với công nghệ

  • Bổ sung về https://projects.blender.org/blender/blender/pulls/116089, inline trước hết ảnh hưởng đến quy tắc một định nghĩa
    Nói đơn giản, nếu bạn định nghĩa một hàm trong header và gọi nó từ nhiều file .cc, linker sẽ báo lỗi trừ khi bạn đánh dấu nó là inline
    Tác động của nó lên tối ưu hóa inline thực tế dao động từ “không có” đến “compiler có thể gán trọng số khác vì cách liên kết”, cho tới “thực sự xem như một gợi ý”, và trong tối ưu hóa thời gian liên kết cũng có các cân nhắc tương tự
    Nếu muốn gửi tín hiệu inline mạnh hơn nhiều cho compiler, đặc biệt là với hàm chỉ dùng trong file nơi nó được định nghĩa, tốt hơn nên định nghĩa nó trong anonymous namespace
    Ý định ban đầu khi thêm inline cho hàm đó có thể là nhằm cố đạt được inline hóa thực sự. Lợi ích đo được không rõ ràng, nhưng cũng không phải là không thể